Hi I am running into a strange issue, that is when I am working, all of a sudden the cookies are not set properly in the response from Web API.
I am using Web API 5.2 and it sets a cookie [OWIN] and the client application reads the cookie and then authenticates via the Cookie Authentication Middleware.
It was working fine, but the cookies were not set suddenly. When I restart the PC, it all started to work fine.
I have had this issue when the datetime was changed in the machine, however it happens all of a sudden in normal cases also.
Anybody have already faced this kind of issue, please share your findings.
Note: We are using the WebAPI as our Authorization Server and the Client application is an ASP.Net MVC 5.2 application.
We are using Redis cache as the session state manager.
Since, we were using Redis Session-State, we were not getting the cookies set properly.
However, when I googled, i found that the set-cookie header was being overwritten and hence the cookies set earlier were lost. This was due to a situation where the ResponseCookies collection were serialized into the headers.
However, the solution was suggested to initialize the session to begin before the authentication happens. This was tried and is working fine.
Hope this helps someone who may encounter it in future.
ASP.NET_SessionId + OWIN Cookies do not send to browser
Related
Orbeon is integrated into another webapp. oxf.http.state is set to none.
When loading a form in form runner, external session cookies are not forwarded to the persistence. Despite that oxf.http.forward-headers and oxf.http.forward-cookies are set to according values.
When loading a simple form which isn't rendered by form runner the cookies are nicely forwarded with the requests in preprocessing step to the same server.
And after loading a simple form and forwarding session cookie atleast once, all the request from form runner also contain that cookie till the session expires.
So the question is - is it possible to forward external session cookies to the same server from form runner to custom persistence layer?
Or the only way is to make a dummy request each time to add the cookie to the http client?
As mentioned in a comment, this looks similar to issue #1070, that was marked fixed for 4.3, as the problem wasn't happening with that version. So I recommend you upgrade to 4.3.
If the problem persists with the latest version, I'd recommend you update your question with specific steps we can follow to reproduce this.
Our mobile app recently stopped authenticating properly with our server on our staging and staging2 environments. Fortunately production is fine.
We're using force_ssl in our API's Session and Registration controllers. It was working fine before; not really sure what changed.
What seems to be happening is that our app submits a POST request to either create a new session or user. This request is over SSL, but we get a 301 Moved Permanently with a location identical to the initial request. I believe this redirect is performed via GET and since no routes match a GET to that URL, we then get a 404 Not Found.
I can't figure out why this changed recently and why it's not affecting production.
Turns out it was something having to do with Engine Yard, and an upgrade of our environment solved the problem.
I am working on an ASP.NET MVC 4 application. I have created few cookies and did not set any expiration time on it. When I am doing a RedirectToAction, all the cookies are getting deleted. I am not sure what I am missing here. Following is the code I wrote to create and access cookies:
Creating cookies:
HttpCookie authorizedCookie = new HttpCookie(AuthCookieName);
authorizedCookie.Value = authorized.ToString();
Response.SetCookie(authorizedCookie);
Accessing Cookies:
authorized = Request.Cookies[AuthCookieName] != null ? System.Convert.ToBoolean(Request.Cookies[AuthCookieName].Value) : false;
When I am trying to access the cookies, the cookie collection is always empty.
Update:
I have also tried setting the domain, expiration time, httponly and yet nothing seems to work. When I look at fiddler, the cookies just seems to be deleted immediately after the redirect.
Response.SetCookie() only updates existing cookies. Use Response.Cookies.Add().
I am able to create the cookies now. The issue seems to be with my IE settings. I reset the browser to its initial state and the cookies are working fine.
I am still not sure which setting was causing the issue. Because of this I am still not convinced to use the cookie approach. Currently my website is heavily dependent on cookies and any issues with the user's browser will render my website useless. I am planning to replace the cookie approach.
Thanks for all your responses.
In my application I have an embedded jetty server (version 8.1.2) running a web application that uses spring web security.
The jetty server is configured to use the JDBCSessionManager
One of the security filters that spring employs is a subclass of AbstractAuthenticationProcessingFilter, in it, it has a SessionAuthenticationStrategy which by default is a SessionFixationProtectionStrategy. This protection strategy creates a new session, as a copy of the original session and invalidates the old one.
Now when I try to login to the web application, I see that a new session is created, but the authentication attributes that are added to the new session are not written back to the database. Moreover, I see that the old session is written to the database with new attributes even though it was invalidated.
Finally, when a new http request arrives as part of the new session, it does not pass authentication because of the above.
After some investigation, I found that this behavior does not happen in older versions of jetty (I tried 7.1.4), and I see that the new session data is written to the database.
I could of course solve this issue by any of the following:
Use an older version of jetty
Disable the session fixation protection strategy
Use the default session manager instead of the JDBCSessionManager
But assuming non of the above options are valid for me, I was wondering if there is any solution to this problem.
Thanks!
Resolved in newer releases of jetty 8, at least 8.1.6 :)
ASP.NET MVC2
.NET 3.5
FormsAuthentication
URL: domain.com/myapp
Problem area: Dynamically created PDFs returned as FileContentResult
Everything was working fine until IE8. With IE8, when the user opens a PDF and then returns to the app, he has lost his authentication. I added an expiry on the forms auth cookie and the problem appeared to be resolved. However, I later discovered that the same problem occurs in the parent app. With the persistent cookie, when the user continues in my app (domain.com/myapp), everything is fine, but when he returns to the parent app (domain.com) window he has lost his authentication. The parent app uses a proprietary authentication and authorization architecture that relies on session state.
So my understanding of the problem is that the FileSystemResult does not carry any session information and thus the session is lost. I understand that by adding an expiration to the cookie, the cookie is persisted and that enables the authorization to persist in my app, even when docs were opened.
I don't quite understand why adding an expiry to my cookie transferred the problem to the parent app. So, I was wrong, this has been happening all along in the parent. Interestingly, when I hooked up Fiddler to watch what was going on, the problem went away.
Do you have suggestions to resolve this? I can't think of anything other than something really ugly like writing the file to the server and returning a page with a link to open the file directly.
Based on this question I think I am hosed.
There's some changes to the way IE8 handles persistance cookies which could be the route of your problems. There's an interesting post here that describes a possible solution.
The solution took us quite a while to find online believe it or not,
and when we found it we wanted to kick ourselves for not finding it
sooner. It all stems from the domain attribute of the forms
authentication settings within the web.config file of your
application. We typically left that attribute blank in our apps to
make it easier to develop. Further, none of the other browsers above
cared about that setting and functioned just fine. However, that
changed in IE8 and now that attribute is required.