This question already has answers here:
Setting cookies for subdomain
(2 answers)
Closed 7 years ago.
I'm building a web app that uses http only cookie sent by the backend for session data. Now my backend is hosted at xyz.domain.com
My client side is domain.com (note - m not using www.domain.com )
Now when the client receives cookie , the browser doesn't save it. In crome i saw the cookie isn't first party.
After doing a bit of research i figured out to send cookie with domain - .domain.com
Tried that. Didn't work.
How should this be done.
Thank you
You should set domain attribute as your domain:
domain= .domain.com
If you can say which language are you working on and what have you tried so far, people may provide some good examples.
Related
This question already has answers here:
How does the 'Access-Control-Allow-Origin' header work?
(19 answers)
Why doesn't adding CORS headers to an OPTIONS route allow browsers to access my API?
(36 answers)
firebase hosting blocking script due to CORS issue
(8 answers)
Closed 4 years ago.
First of all, I'm sure that this is a duplicate question, but I'm a bit far from web techs, and couldn't understand what the hell is CORS, why it is blocking a simple HTTP request and how can I bypass it.
I'm trying to create an Angular 5 + Node.js web app, hosted on Firebase Hosting, and have an Elasticsearch instance on Google Cloud Platform. All I need to do is send 2 very basic HTTP requests to the ES instance from this web app. I'm already sending these requests from mobile apps and Postman app, and there is no problem. But web app logs Preflight response is not successful error. I googled the error and see that it is thrown by CORS. As I said, I have no idea what the hell is CORS and how to bypass it. Any help please (simple help to a non-web-developer). Thank you.
Shortly, CORS (Cross-Origin Resource Sharing) is a security mechanism enforced by default by the browser which specifies what resources (on which servers) your application can use (make requests for). This is a good explanation of CORS - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
So you have to set on your server the domain of your application as being one of the domains allowed to make calls. If you do so, the preflight request will return with an Access-Control-Allow-Origin header set and the browser allows the actual request to be sent.
You can have a look here to see how to do it in Firebase - https://groups.google.com/forum/#!msg/firebase-talk/oSPWMS7MSNA/RnvU6aqtFwAJ
This question already has answers here:
Benefits of a redirecting page after logging in
(2 answers)
Closed 8 years ago.
I see a lot of websites that do a redirect to another page after a user logs in. Sometimes I even see websites that show something like You will be redirected in 5 seconds... while showing in the header that the user is not logged in.
All I would do is to create the session before doing anything else and then show the home page or something like that. Is this bad practice? And if yes, why?
It's not bad practice to redirect directly without showing a redirect page, this mechanism is used in huge network sites like google because Cookies are valid on only one sub-domain and big sites have lots of sub-domains. when you login on youtube.com, you are redirected to accounts.google.com where you enter your credentials. next time you login on another google website accounts.google.com will retrieve the cookie that says you're logged in and you won't have to enter your credentials. But on a small website with only one domain you don't need a redirect website
This question already has answers here:
Is HTTP header Referer sent when going to a http page from a https page?
(4 answers)
Closed 8 years ago.
I commonly hear that since Google employs SSL for their search page, it hides your search queries. But the query is also kept in the URL eg.
https://www.google.com/search?q=stackoverflow
and since SSL does not have the capabilities for masking the URL, the query is visible to anyone sniffing the network.
Am I correct that the search queries on Google are not hidden due to SSL?
No, URLs cannot be seen by network sniffers (as long as SSL is being used). They are first translated into IPs by the client then sent through the network, returning the result back to the client. You can see how it works here.
This question already has an answer here:
Multiple domains, single node (express) app
(1 answer)
Closed 8 years ago.
I'm trying to build an app that generates individual websites.
The idea is for the owner to register his domain, tell it to my platform, point it to my amazon server (still not sure how too).
Then on my express.js server I serve content based on the domain the request is coming from.
You can get the requested hostname from the headers from a field called 'host'. For a node http.ServerRequest, it's available at request.headers.host. For an express app, it can be accessed from req.get('host'). With the hostname, you can route calls from different hostnames to different responses.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
We recently changed our login to use HTTPS, and we are experiencing issues with the login.
After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.
The cookies are not set as https-only, but it seems like they don't work on http pages.
Does anyone know why this might be happening.
Edit:
I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).
I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.
We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.
The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".
The solution we ended up is based on the message in this forum
http://forum.java.sun.com/thread.jspa?threadID=197150&start=0
Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.
As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.
(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).
Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?
When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.
The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.
I don't know much about this, but here are a couple of references:
http://forums.sun.com/thread.jspa?threadID=197150
http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html
If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.