By using AWS re:Post, you agree to the Terms of Use
/Website Provisioning/

Questions tagged with Website Provisioning

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

I'd like to request to S3 as a cognito certification qualification.

I'd like to request to S3 as a cognito certification qualification. S3 is using sdk Cognito is using amplify. Use an angular typescript. I would like to replace the secret key with the cognito authentication information when creating S3. I want to access s3 with the user I received from Auth.signIn, but the credentials are missing. I need your help. ``` public signIn(user: IUser): Promise<any> { return Auth.signIn(user.email, user.password).then((user) => { AWS.config.region = 'ap-northeast-2'; AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: 'ap-northeast-2:aaaaaaaa-bbbb-dddd-eeee-ffffffff', }); const userSession = Auth.userSession(user); const idToken = userSession['__zone_symbol__value']['idToken']['jwtToken']; AWS.config.region = 'ap-northeast-2'; AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: 'ap-northeast-2:aaaaaaaa-bbbb-dddd-eeee-ffffffff', RoleArn: 'arn:aws:iam::111111111111:role/Cognito_role', Logins: { CognitoIdentityPool: 'ap-northeast-2:aaaaaaaa-bbbb-dddd-eeee-ffffffff', idToken: idToken, }, })); const s3 = new AWS.S3({ apiVersion: '2012-10-17', region: 'ap-northeast-2', params: { Bucket: 'Bucketname', }, }); s3.config.credentials.sessionToken = user.signInUserSession['accessToken']['jwtToken']; s3.listObjects(function (err, data) { if (err) { return alert( 'There was an error: ' + err.message ); } else { console.log('***********s3List***********', data); } }); } ``` bucket policy ``` { "Version": "2012-10-17", "Id": "Policy", "Statement": [ { "Sid": "AllowIPmix", "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "arn:aws:s3:::s3name/*", } ] } ``` cognito Role Policies - AmazonS3FullAccess ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", ], "Resource": "*" } ] } ```
0
answers
0
votes
5
views
I need help
asked 11 days ago

AWS Managed AD ADFS user sign-on URL is not accessible outside of ADFS server.

We have setup a test ADFS on a Windows Server 2019 EC2 in our AWS Managed Active Directory. We have enabled the ADFS sign-on page (example URL: https://sts.contoso.com/adfs/ls/idpinitiatedsignon.aspx). ADFS is successful for signing in with our AD credentials, and for accessing our AWS Console when tested from our ADFS server. The issue is that this URL is only opening when directly logged into the ADFS Windows Server. This sign-on URL is not available from another Windows 2019 EC2 test server that is within the same VPC and subnet. All Security Group ports, and Windows Firewalls are temporarily off on both EC2s. The servers can ping each other and using Nmap it displays all the open ports on the ADFS server. Route 53 has a hosted zone for this AWS Managed domain name, and both the ADFS server and test Windows 2019 server have DNS entries for them. We need to test accessing the ADFS sign-on from outside of the ADFS server. Is there another ADFS URL that is for this purpose or another ADFS configuration that is missing? Both links below were used for setting up ADFS on AWS Managed AD https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/ https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/ Thank you.
1
answers
0
votes
4
views
AWS-User-4415410
asked 24 days ago
1
answers
0
votes
4
views
devtwo
asked 2 months ago

Route53 not resolving custom domain for CloudFront

I have set up an S3 bucket to serve a website via https using CloudFront. Within that bucket, I have a folder for each environment and a set of version folders within the production folder: ``` my-bucket |-dev |-prod |-v1.0 |-v1.0.1 ...etc. ``` My initial (development) attempt worked fine using https://dev.mydomain.org, but when I decided to change the alternate domain name in the CloudFront distribution to the production name (i.e. https://mydomain.org and https://www.mydomain.org) and updated the Origin path, it stopped working. I am using Route53 to manage DNS and I haven't deleted the hosted zone. As far as I can tell, all the name server entries match like they're supposed to (makes sense, given I haven't touched the zone). I HAVE removed and recreated AAAA alias records that point to my CloudFront distribution with the two alternate domain names. Several times. No dice. I have also removed the alternate domain names from the distribution and re-added them. (I re-created the Route53 AAAA records after changing the distribution.) I can dig my domain without error. The Route53 test also comes back fine (for what it's worth). However, if I try to ping or curl, I get 'unknown host' errors. Visiting https://mydomain.org in a browser similarly returns a DNS_PROBE_FINISHED_NXDOMAIN response. In case it's relevant, I have this function attached to my distribution to re-route https://www.mydomain.org requests to https://mydomain.org: ``` function handler(event) { var request = event.request; var headers = request.headers; var host = request.headers.host.value; if (host.startsWith('www')) { var response = { statusCode: 301, statusDescription: 'Moved Permanently', headers: { location: { value: 'https://' + host.replace('www.', ''), }, }, }; return response; } return request; } ``` However, unlinking the function doesn't resolve the issue. (I have tested the function in the AWS console and it seems fine.) CloudFront itself seems to be OK. If I hit the CloudFront domain (e.g. d3abcdefghi123.cloudfront.net), I can see the site in all its glory. I have created a TLS/SSL certificate through ACM that covers both the apex and wildcard. I don't think there's a problem there. Something just refuses to resolve my custom domain to the CloudFront distribution. I know DNS changes can be slow - maybe I'm just too impatient? I don't want to create a new CloudFront distribution if I can help it - surely it's possible to update the Origin path and alternate domains? Given the site works fine through the default CloudFront domain, I don't *think* I need to invalidate it either. I'm out of ideas at this point, so suggestions would be most welcome. Regards, Flic
1
answers
0
votes
7
views
Flic
asked 2 months ago

Amplify build failed because the bucket already exists

Hi, I am trying to deploy an amplify app as per https://webapp.serverlessworkshops.io/staticwebhosting/deploy/ but the build is failing because of an existing bucket I am unable to see the bucket in S3. How can I delete the bucket? or how to resolve this issue? ``` 2022-02-25T03:31:32.457Z [INFO]: An error occurred when creating the CloudFormation stack 2022-02-25T03:31:32.459Z [WARNING]: ✖ Root stack creation failed 2022-02-25T03:31:32.464Z [INFO]: AlreadyExistsException: Stack [amplify-wildrydes-prod-32220] already exists at Request.extractError (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/protocol/query.js:50:29) at Request.callListeners (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:106:20) at Request.emit (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:78:10) at Request.emit (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:686:14) at Request.transition (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:22:10) at AcceptorStateMachine.runTo (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/state_machine.js:14:12) at /root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/state_machine.js:26:10 at Request.<anonymous> (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:38:9) at Request.<anonymous> (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:688:12) at Request.callListeners (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:116:18) at Request.emit (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:78:10) at Request.emit (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:686:14) at Request.transition (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:22:10) at AcceptorStateMachine.runTo (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/state_machine.js:14:12) at /root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/state_machine.js:26:10 at Request.<anonymous> (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:38:9) at Request.<anonymous> (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/request.js:688:12) at Request.callListeners (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:116:18) at callNextListener (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/sequential_executor.js:96:12) at IncomingMessage.onEnd (/root/.nvm/versions/node/v14.18.1/lib/node_modules/@aws-amplify/cli/node_modules/aws-sdk/lib/event_listeners.js:335:13) at IncomingMessage.emit (events.js:412:35) at IncomingMessage.emit (domain.js:475:12) at endReadableNT (internal/streams/readable.js:1334:12) at processTicksAndRejections (internal/process/task_queues.js:82:21) { code: 'AlreadyExistsException', time: 2022-02-25T03:31:32.456Z, requestId: '92bb3d71-1610-43c4-a385-54cb25e459cd', statusCode: 400, retryable: false, retryDelay: 81.16703459454344 } 2022-02-25T03:31:32.487Z [ERROR]: !!! Build failed 2022-02-25T03:31:32.487Z [ERROR]: !!! Non-Zero Exit Code detected 2022-02-25T03:31:32.488Z [INFO]: # Starting environment caching... 2022-02-25T03:31:32.488Z [INFO]: # Environment caching completed Terminating logging... ``` Thank you
0
answers
0
votes
6
views
Sri
asked 3 months ago

Amplify GitHub integration failing in ca-central-1

We have multiple Amplify applications running in multiple regions. Yesterday we tried to connect a new branch to an application in ca-central-1. We were sent to the "AWS Console Add Repository Branch" screen, like usual, but then redirected to GitHub where we were asked to install the aws-amplify application. On GitHub we were then asked to pick the specific repositories that AWS-Amplify could access. I had never seen this screen before and it is not the workflow shown in the Amplify documentation. I selected the repositories to which AWS-Amplify ALREADY has access. The workflow stopped at that point; it dit not ask me which branch to connect. I went back to AWS Amplify console and tried again. Same issue. I was not given a chance to choose a branch. I repeated this a few more times. Then I tried it in us-east-1. It worked as normal. Then I tried to create a new web application in ca-central-1. One of the first screens asks me to choose a repository. When I chose GitHub I was sent to GitHub, just like what had happened when I tried to connect a branch in ca-central-1 and the workflow stopped - I could not create the application. I tried to create a new web application using manual deploy. It worked. Now, when I try to connect a branch to the same application that I had problems with yesterday, it works. I found no questions about this when Googling nor any issues reported on the AWS status/health check pages. It started yesterday or on the weekend- we successfully attached new branches and deployed them for the same app/region on the weekend. I'm sorry that I don't have screen shots. This is my first re:Post question and I wanted to see how it works (i.e. are attachments even allowed) prior to gathering that information, and now, of course, things are working. Is anybody aware of any region specific hiccups with AWS-Amplify GitHub integration over the weekend.
0
answers
0
votes
3
views
Jeff
asked 3 months ago

CloudFront returning header does not include settings

Hello I have configured my CloudFront to use a custom response header CORS policy: Cross-origin resource sharing (CORS)Info Access-Control-Allow-Credentials true Access-Control-Allow-Headers content-type Access-Control-Allow-Methods GET OPTIONS Access-Control-Allow-Origin https://www.xxx.com Access-Control-Expose-Headers - Access-Control-Max-Age (seconds) 600 Origin override request header: GET /index.m3u8 HTTP/2 Host: cdn.xxx.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0 Accept: */* Accept-Language: zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate, br Origin: https://www.xxx.com Connection: keep-alive Cookie: CloudFront-Policy=xxx; CloudFront-Signature=xxx; CloudFront-Key-Pair-Id=xxx; Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-site TE: trailers response header: HTTP/2 200 OK content-type: application/x-mpegURL date: Mon, 07 Feb 2022 17:24:34 GMT last-modified: etag: server: AmazonS3 content-encoding: gzip vary: Accept-Encoding x-xss-protection: 1 x-frame-options: SAMEORIGIN referrer-policy: strict-origin-when-cross-origin x-content-type-options: nosniff strict-transport-security: max-age=31536000 access-control-allow-origin: https://www.xxx.com vary: Origin x-cache: Hit from cloudfront via: cloudfront.net (CloudFront) x-amz-cf-pop: HKG62-C2 x-amz-cf-id: 6K23FSOHSfGJli3mnSFRfs4nvYXgKw68Ul_s8b5PUsKLg1HrzLqL8w== age: 3929 X-Firefox-Spdy: h2 I try to use HLS request. The response include access-control-allow-origin:https://www.xxx.com. But not include Access-Control-Allow-Credentials.
0
answers
0
votes
3
views
AWS-User-0708907
asked 3 months ago

DNS Propagation

Hi, As a quick background: Last year we bought a domain from GoDaddy later transffered it to AWS to be our registrar. We had the NS records for AWS and it was fine. We are also connected to Office365, which required us to update the NS records to microsoft ones and modify TXT and MX records. The issue is that there are some moments, where for a few people in specific domains, they cannot access the domain/website. The domain name cant be resolved at all and it causes multiple issues. It occurs every once in a while and consistently on some networks. When we run the dig command with the GTLD, we get (not disclosing domain due to privacy issues): ``` <DOMAIN>. 172800 IN NS ns-641.awsdns-16.net. <DOMAIN>. 172800 IN NS ns-411.awsdns-51.com. <DOMAIN>. 172800 IN NS ns-1689.awsdns-19.co.uk. <DOMAIN>. 172800 IN NS ns-1192.awsdns-21.org. ``` and they are still pointing to the old records, whereas other major public DNS services already have the correct updated information: ``` ~$ dig <domain> @1.1.1.1 NS +short ns4.bdm.microsoftonline.com. ns1.bdm.microsoftonline.com. ns2.bdm.microsoftonline.com. ns3.bdm.microsoftonline.com. ~$ dig <domain> @8.8.8.8 NS +short ns1.bdm.microsoftonline.com. ns2.bdm.microsoftonline.com. ns3.bdm.microsoftonline.com. ns4.bdm.microsoftonline.com. ~$ dig <domain> @9.9.9.9 NS +short ns1.bdm.microsoftonline.com. ns2.bdm.microsoftonline.com. ns3.bdm.microsoftonline.com. ns4.bdm.microsoftonline.com. ``` Why has this change not propagated and how can we get around to fixing this? Cheers
1
answers
0
votes
5
views
fw-spbelani
asked 3 months ago

Unable to fetch images from cloudfront cdn using fetch API in the browser

I keep getting `'Access-Control-Allow-Origin' header contains multiple values '*, *'` when using `fetch` API to get images from my cloudfront cdn. A sample URL that demonstrates this problem is `https://cdn.dev.textras.com/images/6158ac8f8074530013f8dcde/77b4b530-738c-11ec-ae4a-1d90956db63a.jpeg?w=320&q=100&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYxNTFiZTZkMDJkYmM3MDAxNDIzMDhhZiIsImNvdW50cnlDb2RlIjoiTkdBIiwiaWF0IjoxNjQzMjE4ODE2LCJleHAiOjE2NDM0NzgwMTZ9.m2zcZJ0pv-Sj1q7Mz8w9GNoxzLiHBSCf3Yd8qu-YE4s`. If you use that url as the `src` for an `<img>` tag, the image loads. If you visit the URL in a browser tab, the image loads. If you open dev tools within that same tab and then do a `fetch` request to get the image (i.e. same origin), the `fetch` request succeeds. If you request the image using postman or `curl` from the terminal, the request succeeds. However if you're in a browser tab with a domain different from my cdn (i.e. cross origin), it doesn't load. There are lots of questions about this on the internet and the root cause is always that the server is setting the header multiple times in different places. However, I'm unable to identify where this is happening in my case. This is a snippet from the template that defines the behavior of the cloudfront distribution. I'm only including the part that defines the behavior that affects this particular image: ``` ... CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Aliases: !Ref AliasesParam Comment: !Ref Comment CacheBehaviors: - AllowedMethods: "DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT" CachedMethods: "GET,HEAD,OPTIONS" Compress: false PathPattern: 'videos/thumbnails/*' DefaultTTL: "1814400" ForwardedValues: QueryString: true QueryStringCacheKeys: - w - h - t - q - v LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn - EventType: 'origin-request' LambdaFunctionARN: !Ref LambdaVideoPathEdgeVersionArn - EventType: 'origin-response' LambdaFunctionARN: !Ref OringResponseFunctionVersionArn MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" # TrustedSigners: # - String ``` You can see that the template doesn't specify a response header policy, so I'm sure the duplication is not happening from here. I've checked the CORS config on the s3 bucket and it's this: ``` [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "POST", "GET", "PUT", "DELETE", "HEAD" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [ "String" ], "MaxAgeSeconds": 3000 } ] ``` So the s3 bucket sets the header. The associated `origin-response` lambda was setting this header too, like this: ```js response.headers['Access-Control-Allow-Origin'] = [ { key: 'Access-Control-Allow-Origin', value: '*' }, ]; ``` I thought this may be the source of the duplication so I commented it out, but the error remained. So the way I'm looking at this is: out of the 3 places that could be setting the header's value (cloudfront distribution, origin s3 bucket, and the lambda for processing image) there's only one place still setting this CORS header, and it's the s3 bucket. Yet the problem is still happening. What other place can/should I look at? Thanks!
0
answers
0
votes
10
views
AWS-User-8778696
asked 4 months ago

Instance will no longer connect to Bitnami/website MIA

Hello,my name is Justin and I own a smaller company in Virginia, and thank you in advance for your help and guidance. I started working on a new domain/website several weeks back after getting the technical end set up first and surprisingly I've had no issues until now. My set up is Google domain to AWS (basic plan/$3.99/month), using Lightsail and WordPress. I followed the set up for my instance from an AWS certified specialist on YouTube. That said, I have not set up anything for storage/containers/etc tho I do have my static page set up for my landing page. So, Sunday night I finished working on the site on wordpress with no issues outside of a jetpack warning that had been up for 2 days. It stated that my domain name and IP address were both fighting for the same spot and I needed to select one or it would go into safe mode. Outside of this, my primary updates outside of verbage was in installed a few plug ins. The last one was PayPal which was around $60 for the year. I went thru the process of setting all the pages up and everything worked great. The following morning I had planned on fixing the jetpack issue but once I logged on, or attempted to, I realized that the website was down. All pages refused to load and a few times I got a 504 gateway timeout error message. I attempted to log in thru WordPress but I had the same issue, no loading. I then attempted to relaunch the instance via AWS; however, the instance wouldnt connect correctly to Bitnami. Basically, the black terminal screen comes up but is empty. I then created a second instance (can only have 2 max) and attempted to connect to Bitnami again. This time, it was a success. Circle back to verify and my instance 1 still has the same results of not completely connecting to Bitnami. I'm new, and have a basic account,meaning no technical support. Any help would be GREATLY appreciated!! Sincerely, Justin
0
answers
0
votes
9
views
AWS-User-2354556
asked 4 months ago

Authenticating a Cognito User in Browser JS using tokens from cognito itself as an Identity provider

Hi, We have a multiplatform app consisting in an Android app and a website that share a User Pool for the login procedure. In the browser, for the login, we use without any problem the flow described in case 4 @ https://www.npmjs.com/package/amazon-cognito-identity-js : ``` var authenticationData = { Username: 'username', Password: 'password', }; var authenticationDetails = new AmazonCognitoIdentity.AuthenticationDetails( authenticationData ); var poolData = { UserPoolId: '...', // Your user pool id here ClientId: '...', // Your client id here }; var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData); var userData = { Username: 'username', Pool: userPool, }; var cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData); cognitoUser.authenticateUser(authenticationDetails, { onSuccess: function(result) { (...) ``` We also have an android application where users can also login using the Amplify framework, the login works as described in https://docs.amplify.aws/lib/auth/signin/q/platform/android/#sign-in-a-user ``` Amplify.Auth.signIn("username", "password", { result -> if (result.isSignInComplete) { Log.i("AuthQuickstart", "Sign in succeeded") } else { Log.i("AuthQuickstart", "Sign in not complete") } }, { Log.e("AuthQuickstart", "Failed to sign in", it) } ) ``` But, now, we need to authenthicate the users in another browser scenario (a webview inside the android Application) without asking for a password or username (as they are using the app, they already logged), I guess using the tokens generated in the Android login. I don't see any way to do such an authenthication using methods described in: https://www.npmjs.com/package/amazon-cognito-identity-js I'm tempted to use in the browser webView, as described in https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/loading-browser-credentials-cognito.html, ``` AWS.config.credentials = new AWS.CognitoIdentityCredentials({ IdentityPoolId: '<the pool that is shared by android and browser app>', Logins: { 'cognito-idp.<region>.amazonaws.com/<the_POOL_ID>': <the_jwt_token_derived_from_the_android_login?>, } }); ``` But this is not working at all. The AWS.config.Credentials show an expired token and no login has been made, I cannot retrieve a Cognito Session. Does anyone know how to handle this situation? Thanks in advance for you time
0
answers
1
votes
9
views
carlos
asked 4 months ago

Cloudfront Multiple Distributions Automatic Directs

Hello, I have a question, I have 2 cloudfront distributions with 2 different certificates / domains that point to the same S3 Bucket # main distribution is 123456789.cloudfront.net, with alternate domain + certificate: main.mydomain.com # second distribution is 987654321.cloudfront.net, with alternate domain + certificate: sub1.otherdomain.com On DNS (I use cloudflare) I have a CNAME for the main distribution domain: # main.mydomain.com cname to 123456789.cloudfront.net and I add other subdomains pointing to this other CNAME (for better management as I have many subdomains): # sub1.mydomain.com cname to main.mydomain.com but I also do point subdomain from the other domain to this (again because of management and some hardcoded links, **so I can't point it to it's own distribution**): # sub1.otherdomain.com cname to main.mydomain.com On theory I would need to use **cloudfront function to redirect the sub1.otherdomain.com to it's distribution (987654321.cloudfront.net)**, but it works without it and I don't know why (it shouldn't or there is some universal property of cloudfront I'm not aware about), because **there is no pointing / redirect from first distribution to the second one** configured, the **only DNS pointing to cloudfront is from main.mydomain.com** (cname to 123456789.cloudfront.net), and the **certificates are different**. Is it expected? Need to be sure for not having headaches on the future with production stuff.
1
answers
0
votes
7
views
Emerson Junior
asked 4 months ago

Cognito Authorisation Server - Is there a vulnerability when using PKCE flow?

We're using the Cognito Authorisation Server alongside a custom frontend UI to authenticate users into our web apps. Our web apps have an SPA architecture so we're using Authorisation Code with PKCE as our OAuth flow. Our login page uses the Amplify-JS Auth module to handle the process: 1. Amplify redirects the user to the AUTHORISATION endpoint (which includes the PKCE parameters `code_challenge_method` and `code_challenge`) 2. User logs in via SAML 3. User is redirected back to our app and Amplify submits the code (along with PKCE parameter `code_verifier`) to the TOKEN endpoint in order to get the JWTs In order for this to work it's necessary to create a Cognito app client without a secret. It's my understanding that PKCE is a protocol designed to work in this very case - where the authorisation server is being accessed from an insecure channel (ie browser or app) such that a client secret couldn't be trusted. It was my assumption that in this case, it shouldn't be possible to exchange the code for a token without the PKCE parameters. However I'm finding it is possible: 1. Construct URL from #1 above without the PKCE parameters (this is fairly straight forward since the rest of the values are hardcoded) 2. Follow link and intercept `code` parameter on redirect URL 3. Send the following to TOKEN endpoint without an Authorization header ``` POST /oauth2/token grant_type: authorization_code code: {INTERCEPTED_CODE} client_id redirect_uri ``` A 200 Response is received along with the JWTs. Reading around it seems that an approach is to force public clients to use PKCE: https://www.oauth.com/oauth2-servers/pkce/authorization-request/ >Since the authorization server should know that a specific client ID corresponds to a public client, it can deny authorization requests for public clients that do not contain a code challenge. Seems like this would be useful in this case, but I might be missing something. Is anyone able to advise? Thanks
1
answers
0
votes
8
views
robsquires
asked 5 months ago

Cognito AUTHORIZATION endpoint - Error handling

We're using the Cognito Authentication server to log in users via SAML and OIDC from a custom frontend UI. The AUTHORIZATION endpoint URL (ie. https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?) is being constructed in a client-side JS app and the user is being redirected using JS (ie. window.location) Note: We're using the Amplify-JS Auth module to do this. I'm struggling with error handling... The documentation outlines error responses here https://docs.aws.amazon.com/cognito/latest/developerguide/authorization-endpoint.html One error case from Docs: ----- If client_id and redirect_uri are valid, but the request parameters have other problems (for example, if response_type is not included; if code_challenge is supplied but code_challenge_method is not supplied; or if code_challenge_method is not 'S256'), the authentication server redirects the error to client's redirect_uri. HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request ---- In this case, we removed the `response_type` parameter, but the user was redirected to the hosted UI: HTTP 1.1 302 Found Location: https://mydomain.auth.us-east-1.amazoncognito.com/error?error=Required+parameters+missing We've tried a few other error cases, ie providing an unknown `identity_provider` and the same happens...the user is redirected to the hosted UI. Is this a known issue? Should the AUTHORIZATION endpoint be working as the docs describe?
2
answers
0
votes
8
views
robsquires
asked 5 months ago
  • 1
  • 90 / page