I'm building a Sinatra app which needs to use a session variable for one very specific thing. The session variable is set when the user is looking at an SSL enabled page.
I'm using Heroku's piggyback SSL, so the SSL url is something like https://myapp.heroku.com
However, the app itself is hosted at my url, myapp.com
Is there a way to make my session variable, which is set while on the ssl / heroku domain name, available to my app while while on my domain name?
Unfortunately no, since the cookie is tied to the domain. What you'll have to do is either allow authenticated users to use the https://foo.heroku.com domain, and reserve your nice domain for the landing page & other unauthenticated pages.
That, or pay $20 for heroku's SSL add-on.
(I ran into this exact problem in http://appkickstand.com and I chose to just deal with the heroku url for logged in users)
You should look for cross-domain cookies manuals, check this.
But i don't see many reason in setting cookie through secured channel and transmitting it later via raw HTTP, where everyone could sniff it.
Related
I am currently trying to host a website as an experiment on Heroku, I deployed the back end which you can consider yyyy.herokuapp.com and the front end with you can consider xxxx.herokuapp.com,
Now, here's the issue, I need to set cookies between xxxx and yyyy, I know this will be a massive security issue but since this is an experimental website I am not willing to get a custom domain, I tried to set the cookies' domain to: herokuapp.com, .herokuapp.com, *.herokuapp.com, xxxx.herokuapp.com, yyyy.herokuapp.com.
Yet it doesn't work, chrome denies the cookies and gives this message:
This attempt to set a cookie via a Set-Cookie header was blocked because its Domain attribute was invalid with regards to the current host url.
So, how do I approach this issue without the need for a custom domain?
this is my configuration to set cookies (on the back end which uses flask)
response.set_cookie("example_cookie", value="cookie value",
max_age=900, expires=datetime.datetime.utcnow() +
datetime.timedelta(seconds=900), secure=True, domain=".herokuapp.com",
samesite='none')
If herokuapp.com were not a public suffix (a.k.a. an effective top-level domain or eTLD), then in the case of a cookie set by xxxx.herokuapp.com with Domain=herokuapp.com, browsers would send that cookie to yyyy.herokuapp.com
However, there is a snag: in order to isolate its different tenants, Heroku required herokuapp.com be added to the public-suffix list a while back. Most browsers refuse to set a cookie for a public suffix:
For security reasons, many user agents are configured to reject Domain attributes that correspond to “public suffixes”. For example, some user agents will reject Domain attributes of “com” or “co.uk”.
Therefore, attempts to set a cookie with Domain=herokuapp.com will be rejected by browsers, as you've experienced.
Note: adding a leading dot in the Domain attribute of the Set-Cookie HTTP header has no effect, at least in modern browsers.
To get out of this difficulty, you could simply buy a cheap domain name (say infinityvive.com) to serve both your frontend and backend from subdomains of it. Then you'd be able to use Domain=infinityvive.com because your domain would not be a public suffix.
I am managing two separate apps through two different Heroku pipelines.
App 1 - Handles my auth, this is a login landing page.
App 2 - The main app, can access after authenticating via App 1.
I have separate review apps running for each app. The reasoning was so I can have both Review
Apps under the .herokuapp.com domain.
App 1 takes Username, Password, and sets a JWT. In App 1, a query param is set and it contains a callbackUrl to App2. The JWT is set as a cookie in App 1 and sent to App 2 via a cookie (a token).
This is a problem with the new Same-Site Rules in Chrome. However, I have read various articles and workarounds for this, and my Cookies are still blocked. Here is the error:
the Set-Cookie was blocked because its domain attribute was invalid with regards to the current host url.
I believe they are blocked because the domain .herokuapp.com is on the Public Suffix List, so no matter what I do, they will always be blocked.
Is there a workaround for this? Can I use my own domain with a review app? Ideally:
app1.helloworld.com
app2.helloworld.com
.helloworld.com would be the domain.
Indeed they are blocked due to the domain being on suffix.
But you can block chrome from registering that you are on the suffix list through creating a library with automated deployments similar to hstspreload and then also providing a mechanism that any HTTP library can update the packaged list via their own fetching mechanism.
sadly you cannot reliably exclude .herokuapp.com from the suffix list or any other website for that matter.
for those wanting to see more about attempting to remove from suffix, here are the pros and cons and other theorized attempts:
https://forum.blocsapp.com/t/remove-html-suffix/1643
I have 2 Asp.Net Core 2.2 applications and I want to share session between them.
I've set up session in a SQL database and both connect ok.
They are on different sub domains.
I understand that I can set the Cookie.Domain the startup file, which would solve the problem at a basic level, so each application would create the cookie such that it can be accessed.
e.g.
Domain 1. "www.website.com"
Domain 2. "dashboard.website.com"
At present these sites can't access each others session cookie.
If I set the domain cookie to ".website.com", both should be able to access this.
The problem is that we have multiple domains that use this website, so it could be:
www.domain1.com
dashboard.domain1.com
www.domain2.com
dashboard.domain2.com
www.domain3.com
dashboard.domain3.com
I need to be able to inject the current host name into the startup cookie domain, in order to have it dynamically set, depending on the domain of the active website.
Is this at all possible?
Thanks in advance,
David
No, it's not possible. Cookies are domain-bound. You can set a wildcard for the subdomain portion on the cookie, which would then allow it to be seen by example.com, www.example.com, foo.example.com, etc. but you can cannot share with an entirely different domain altogether, such as example2.com.
Your only option in this case is an Identity provider like IdentityServer, Auth0, Azure AD, etc. The way these work is that the auth cookie is set at the provider, and then each individual app is authorized against that provider. As such, they can receive the user principal from the provider, without having the actual auth cookie or their own login functionality.
UPDATE
If you just need to share between sites on the same primary domain, then follow the instructions in the docs. That's focused on auth cookies. If you need to share sessions as well, the same procedure applies, but you must additionally have a true distributed cache setup (Redis, SQL Server, etc.). There's a distributed memory cache, but that's just a default implementation, and it's not actually distributed.
It's common to use HTTPS for authentication, so the authentication details from client cannot be sniffed. However once the user is logged in then subsequent calls to a web app passing some sort of auth id which then the web app will then use to authorise with, should that not also be HTTPS? How is this done in things like Facebook? Seems easier to make all traffic HTTPS.
An answer by Jeff Atwood:
http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html
Assuming the server can handle it, I'd go a step further and use SSL for everything, no matter if users are logged in or not.
This has the advantage that an eavesdropper doesn't even know if the user is accessing your site/app as a guest or as an authenticated user. It also saves you from having to decide when to use SSL and when not.
I have a problem related to subdomain and https request.
I am trying to route from http to https where my http address is subdomain.domain.com and https address is domain.com/subdomain. But the problem is when i switched from http to https i loose my session variables.
How can i persist my session variables in both http and https requests.
Thank you.
The session is probably tracked by a cookie.
Cookies have a domain associated with them, in this case this would be "subdomain.domain.com". For a different domain, even if it is the parent domain, the cookie will not be provided by the web browser.
I think there are ways to make a cookie valid for all subdomains under a given domain, but you have to look into the documentation of the software you are using for that.
For any more information, we really need more detail about what software you are using to keep this session. Standard PHP sessions? Or something else?