I have Application Insights configured on both the front and back-end of my website, which operate on different sub-domains (let's say www.mydomain.com and api.mydomain.com).
The cookie containing the user information set by setAuthenticatedUserContext is stored by AI with the cookie domain set to www.mydomain.com. When I make a call to api.mydomain.com the cookie is not included, and therefore the credentials I set are not associated with any AI data logged by the API.
My API has Access-Control-Allow-Credentials set to true, and the front-end has withCreditials set to true on the XHR object.
Can I get AI to set a different cookie domain, or is there some other issue at play here stopping the user information reaching the API?
Update: I notice Google Analytics sets a cookie with the domain set simply to .mydomain.com, and this cookie information is included with calls to my API.
This is not currently supported but there is an issue opened on GH for it: https://github.com/Microsoft/ApplicationInsights-JS/issues/64
Please continue monitoring GH link, we will provide an update soon. Thanks!
Related
I am pretty inexperienced with AWS and I have an app that uses a JWT token stored in a cookie to log in users. On page load, a GET request is made to the backend, the backend verifies the token and redirects the user to the dashboard page, which can only be accessed with a valid token. If there's no token, the backend returns a 400 error and the user stays on the home page. This works flawlessly on my local machine but not when I host the project on AWS. I believe there are no problems with how it's hosted because the backend does receive the GET request from the frontend, just without cookies, and I am adding credentials with it. The documentation talks about a Forward Cookies option and so does this video by AWS but the console has since changed and this option is no longer available. The second answer in this post suggests that the right way to do it is via custom cache and origin request policies in a distribution behavior but the example given doesn't match my use case and I haven't been able to get it working. I have tried editing the distribution behaviour and both setting "Cookies" to "All" in the legacy cache settings and using custom cache and origin request policies with the same setting but nothing works.
Axios GET request:
axios
.get(`${backendURL}/isUser`, {
withCredentials: true,
})
.then(() => router.push("/dashboard"))
.catch((error: AxiosError) => console.error(error))
Development (left) and production (right) requests
Distribution behavior unchanged (just HTTP to HTTPS redirection)
This has nothing to do with AWS and everything to do with how you are setting your cookie. You can't set a cookie from your "backend", so that your "front-end" will return it, unless they are on the same subdomain, and the cookie domain setting is set correctly.
I had some similar issues with cookies. #Warren is actually correct here.
If you want to access cookies, you'll have to setup same subdomains for your client and server applications.
However, I tried something earlier and this may work (not sure)
Map the S3 link (client) and server to cloudfront domains. This will make both the domains secure with https. (select a CF certificate, the default one). Now, set the following thing on the server side while setting cookies:
httpOnly: true
sameSite: none
secure: true
This should work I guess, give it a try. Other cloudfront setting you can change has been attached. (That is what I did)
I didn't mention on my post that I was setting the cookies on the frontend of my app, hosted at https://abcdef1234.cloudfront.net/, and trying to send the cookies to my backend, at https://api.mydomain.com/. I didn't think this was an issue but it turns out it is. To get it working, I have had to change my CloudFront distribution to use https://myapp.mydomain.com/ and the backend to set the cookie itself.
I am using authcodeflow with PKCE.
Using OIDC js library in the frontend, making calls to adfs getting an auth code and then calling my backend api. The backend api which calls adfs server get the access token and the backend api returns the token as a cookie to the frontend. I can see the cookie in response headers. but That cookie is not stored in browser and not getting added for subsequent requests. I have tried with samesite with all modes -> Lax, None,Strict and not setting.
Is this an issue with OIDC js library or is it blocking the cookies to store in browser?
Update:
Below are the observation with my analysis
Since the OIdc-client-js does not have an option to set flag "withCredentials" to true for the requests. There are no cookies send in the request and response cookies are ignored for the cross origin requests.This changes are marked as enhancement and still not completed in thier github repo.
https://github.com/IdentityModel/oidc-client-js/issues/1062
Is there any way to achieve with this library? or any other libraries for OIDC js
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
So you are issuing a cookie from an API domain that is a sibling of the WEB domain:
web.mycompany.com
api.mycompany.com
Cookie domain = .mycompany.com
POSSIBLE CAUSES FOR COOKIE BEING DROPPED
Maybe it is the withCredentials flag or maybe due to a lack of user gesture, since the user has not done anything explicit to navigate to api.mycompany.com, such as a browser navigation or clicking a link?
FORCING WITHCREDENTIALS
You can override the prototype like this in order to add the withCredentials property. This is a little hacky but you could limit usage based on the URL and it should let you know whether setting withCredentials resolves your problem:
let open = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url) {
open.apply(this, arguments);
this.withCredentials = true;
}
PROXYING VIA WEB DOMAIN WILL HAVE FEWER COOKIE ISSUES
In my blog post I do something similar to proxy messages containing a refresh token. I use the web's exact domain though, rather than using an API subdomain. This will never be impacted by browser restrictions.
I'm currently working on a REST based SagePay Integration using a combination of Django on the backend and Vue / Nuxt on the front.
The current process is as follows:
Client makes a request to my backend server for a merchantSessionKey via a GraphQL resolver.
The backend graphene resolver uses the secret merchant integration key and password (stored in environment variables) to make a post request for the merchantSessionKey and returns it to the Vue frontend.
A user fills in the credit card form (using SagePay's Own Form integration)
I use the card data to generate a cardIdentifier that I will store in my vuex state and will use later to further the rest of the transaction.
Is this all safe to do? Obviously it will be secured via https and I will setup CORS properly when everything goes into production, but I am technically storing the merchantSessionKey and cardIdentifier on the end users machine.
Both expire after 400sec and must be send together within Payment Registration POST authenticated with your vendor/account IntegrationKey and IntegrationPassword from your server which IP is whitelisted by Sage Pay. MSK is required to authenticate card tokenization call from customer's browser to Sage Pay endpoint. As a result you receive cardIdentifier/Token. This method keeps your server free of cardholder details but all (MSK,Token, PAN and CV2) are allowed to exist in customer browser.
IntegrationKey and IntegrationPassword can't be stored in the customer browser.
If you decide to use your own payment pages instead of drop-in checkout, you can't reference files from 3rd-party non-PCI DSS server to archive PCI DSS SAQ A-EP attestation.
I've reviewed it with QSA
Let's say I have a website at http://domain.org on which I also have Google Analytics (GA) and Mixpanel (MP) Javascript tracking codes. Both MP and GA store cookies on the user's browser for my entire domain including sub domains (.domain.org).
Because of this every time I do a request to any URL in this entire domain, the cookies for GA and MP are sent along.
New Relic on the other hand store their cookie on the bam.nr-data.net domain.
Why do GA and MP do this? Only in a situation of strange backend hackings one would use the values in these cookies on the backend.
Google Analytics uses first party cookies (by injecting the javascript code that's setting the cookie into the web site source) because 3rd party cookies are often blocked (in many browsers they are blocked by default).
Since they are set under your domain name they are sent to your server. That's pretty much a side effect of the original intent (which is to make the tracking more reliable), your are not supposed to use them in your backend.
When setting up Google Analytics you can use the cookie domain parameter to limit ga cookies to a specific part of your domain/subdomain. You cannot, to the best of my knowledge, make GA use a third party cookie.
On a related note, if your goal is to avoid sending the cookie data with each request, you can tell Google Analytics to use localStorage (instead of cookies) to store the client ID.
Here's a thread on the HTML5Boilerplate repo discussing implementation and the pros and cons of such an approach.
The TL;DR is if you don't have to support IE7 and older, and if you're not tracking across multiple sub-domains, you can use localStorage with no problems.
I created a Google site page with 5 links on it. Is it possible to create on my site a script or something that stores in a cookie the link on which the user has clicked, and then the next time he will connect to the page, he will be automatically redirected to the link he clicked on ? For information, the user connect to the site with his Google email account.
How can I do that please?
Thank you very much in advance for your help
While it is possible to read cookies and redirect using JavaScript inside a Google Page (using widgets), browsers will not allow you to set cookies for a completely different domain for obvious security reasons.
Related:
How to set a cookie for another domain
Cross-Domain Cookies
What's your favorite cross domain cookie sharing approach?
You could theoretically try and send an AJAX request from the Google Page with a "where should I direct this user to?" and expect a URL or a null.
See:
CORS $.ajax session cookies (access-control-allow-credentials & withCredentials=true)
Cross domain POST request is not sending cookie Ajax Jquery
But overall, your task is not as straightforward as it may seem. The browser will, fortunately, not play along.