GithubHelp home page GithubHelp logo

Comments (10)

ottokruse avatar ottokruse commented on August 19, 2024 1

Great to hear that!

"You do confirm that we can easily spin-off multiple SPA Distrubtions/Buckets without the lambda@edge functions being redeployed every time, right?"

In the sample solution the userPoolId and such is added into the Lambda@Edge functions (configuration.json). So if you need to use different user pools you need different Lamda@Edge functions.

You can of course change the code, then you can do whatever.

The Lambda@Edge functions are configuration-wise not aware of the bucket they protect, nor of the CloudFront distribution they are used in. So you can re-use the Lambda@Edge functions for multiple S3 buckets/CloudFront distributions.

from cloudfront-authorization-at-edge.

ottokruse avatar ottokruse commented on August 19, 2024 1

Sure! Great.

Shall we close this issue for now?

from cloudfront-authorization-at-edge.

ottokruse avatar ottokruse commented on August 19, 2024

Hi @picosam ! Great to hear this is of use to you.

  • You should only replace "example.com" in the origin "protected-origin" with your own origin domain name (can be an S3 bucket too if that's what you wanna protect). Now that you mention it I see it is indeed confusing with the "dummy origin" example.ORG, I'll try to make that more clear.

  • The dummy origin "example.org" can remain there, as it is the origin behind the Lambda@Edge functions for parseAuth and such; they will always respond to the request instead of allowing the request to pass through to the origin. Hence "dummy origin", it is there because a CloudFront behavior needs to have an origin, but requests will never be forwarded to it.

  • Indeed if you set parameter "CreateCloudFrontDistribution" to false then you need to create the S3 Bucket yourself. I tried to explain that in the parameter description btw: "Set to 'false' to skip the creation of a CloudFront distribution and associated resources, such as the private S3 bucket and the sample React app. This may be of use to you, if you just want to create the Lambda@Edge functions to use with your own CloudFront distribution."

  • If you want a protected S3 bucket, you might as wel set "CreateCloudFrontDistribution" to true, then you'll get an S3 bucket with a sample React app in it. You can just delete that React app and upload your own SPA/files to that S3 bucket.

Let me know if this clears things up.

from cloudfront-authorization-at-edge.

picosam avatar picosam commented on August 19, 2024

Thank you very much @ottokruse, your response is clear and I believe your description was as well; I guess I just assumed incorrectly there was more to dummy-origin than that.

Your code is not only of use but very valuable to us: we're going to be using it to protect our Test and Staging environments, hence the need to use our own CloudFront Distributions. You do confirm that we can easily spin-off multiple SPA Distrubtions/Buckets without the lambda@edge functions being redeployed every time, right?

The thing is that (and I'm going to try and look into that today) I'll have to have a different User Pool for each "set" of Test/Staging environments though, to prevent different protected resources from being accessed by users who shouldn't be seeing them.

from cloudfront-authorization-at-edge.

picosam avatar picosam commented on August 19, 2024

Ok, so I deployed with a pretty complex distribution and it all does work as intended :-)
I guess what I would like to try and change would be indeed to use the exact same Lambda@Edge functions and the same UserPool deployed with different (future) buckets/distributions.

The Lambda@Edge functions are configuration-wise not aware of the bucket they protect, nor of the CloudFront distribution they are used in.

Does that statement stand even relative to the redirect URLs after signing in/out?

from cloudfront-authorization-at-edge.

ottokruse avatar ottokruse commented on August 19, 2024

The Lambda@Edge functions are aware of e.g. the special paths (signin/signout/parseauth/refreshauth), but not of the host (domain name) on which they are running. They grab the hostname from the incoming "Host" http header.

So as long as your CloudFront distributions use the same special paths, you could reuse the Lambda@Edge functions.

from cloudfront-authorization-at-edge.

ottokruse avatar ottokruse commented on August 19, 2024

BTW maybe you could solve your use case more easily by having one user pool, but putting the users in that pool into separate groups. Then, implement some sort of mapping between group and allowed origin. This will require you to change the Lambda@Edge code a bit, but having one user pool might be nicer, as users who are in multiple groups then only have to sign in once.

Update: excuse me, reading back I think you were going in this direction already.

from cloudfront-authorization-at-edge.

picosam avatar picosam commented on August 19, 2024

Thank you! Yes, this is exactly what I'm trying to do: have one user pool -- except I thought I would need to create a different App Client per CloudFront distribution. What's stopping me is the following:

      Configuration: !Sub >
        {
          "userPoolId": "${UserPool}",
          "clientId": "${UserPoolClient}",
          "oauthScopes": ${OAuthScopes},
          "cognitoAuthDomain": "${UserPoolDomain.DomainName}",
          "redirectPathSignIn": "${RedirectPathSignIn}",
          "redirectPathSignOut": "${RedirectPathSignOut}",
          "redirectPathAuthRefresh": "${RedirectPathAuthRefresh}",
          "cookieSettings": ${CookieSettings},
          "httpHeaders": ${HttpHeaders}
        }

as it seems that the App Client ID is being saved "within" each lambda function and I'm looking for how to have that be "dynamic" somehow.

Again, thanks a lot for all this help.

from cloudfront-authorization-at-edge.

ottokruse avatar ottokruse commented on August 19, 2024

Yeah probably implement some kind of mapping between domain names, groups and client id's.

{
  "domainNames": {
    "example.org": {
      "allowedCognitoGroups": [
        "them",
        "others"
      ],
      "clientId": "dfasgfagfasgfsdgsgf"
    },
   ...
  },
  ...
}

That'll be some fun coding, enjoy :)

from cloudfront-authorization-at-edge.

picosam avatar picosam commented on August 19, 2024

Great. If you don't mind, I'm going to ask someone who works with me to contribute via pull requests.

from cloudfront-authorization-at-edge.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.