We are coping with orbeon session management:
We have a custom authentication mechanism that works fine on the server (locally), but we got 403 at every /xforms-server call after login when we are trying to use orbeon remotely.
Our custom authentication happens at tomcat/container level, and the result is a standard JSESSIONID cookie that present in the response of the login request.
The "funny" thing is that this JSESSIONID is present at every "normal" browser request (for resources) except these, so those that are trying to reach the /xforms-server
As if the client side javascript would not set this JSESSIONID cookie for the xhr request.
We already set the cookie forwarding described here
We already set the cookie path descibed here
We already raise the log4j level and orbeon debug but we got only the same info that we have already known, that the sessionId cookie was not forwarded to the server.
Do you have any idea what else we could do?
You are saying that the JSESSIONID cookie is not sent by the browser for Ajax requests. The cookie isn't set by JavaScript. It is set by the server with a Set-Cookie header. For instance, with Orbeon Forms deployed on /démo, if you clear your cookies, the first time you make a request to the server, in the response you will see:
Set-Cookie: JSESSIONID=FAD4923E960D0C0341BC750265222FB6; Path=/demo; Secure; HttpOnly
Note the Path=/demo. This is the server telling the browser "don't send the cookie unless it is a request under /demo. Could you try clearing your cookies, and checking what the header looks like? Does it include the path used for the Ajax request?
It might go without saying, but I'll say it anyway ;), in addition to the path, you need to make sure that Ajax request go to the same server from which the page was loaded, otherwise you have no change that the browser will send the cookie.
Related
Correct me if I'm wrong but cookies are just special Set-Cookie: headers, right? Maybe I'm missing something but that always seemed like the case to me. If I set up a Rails API application and want to support sending HTTPOnly cookies (e.g. headers also assume I've got CORS and everything on the client setup etc) I should be able to do this correct?
Basically, my questions are these:
Does bringing back ActionDispatch::Cookies into my middleware and adding include ::ActionController::Cookies in my application controller totally defeat the purpose of an API application?
If it does, can I just send an HTTPOnly cookie through the headers manually?
And if that is so, is it a much bigger hassle to manage cookie headers manually? Is what I'm gaining from leaving the cookie middleware out out weigh handling them manually, if all I really need to do is send one HTTPOnly refresh token?
So I don't need to add back any middleware or include any classes for cookies. I can use reponse.set_header to send a cookie. However, this only lets you send one Set-Cookie header because it will overwrite the last header you set with Set-Cookie as the key. Instead you have access to response.set_cookie which will let you set multiple cookies with each set_cookie call. It also comes with some options that you can set that you would have to add to the value of the header you were sending manually with set_header.
Here's an example I used that allowed me to send a cookie:
response.set_cookie(
:jwt,
{
value: 'this could be a token or whatever cookie value you wanted.',
expires: 7.days.from_now,
path: '/api/v1/auth',
httponly: true
}
)
Check the documentation for this method for other options because there are others.
EDIT: I was having an issue where the cookie was getting sent in the response but not saved (still). It wasn't showing up in the cookie storage so I changed the path of the cookie getting sent to / and then it showed up. I deleted it and then changed the cookie's path to /my/real/path and it worked and was stored in cookie storage. Go figure.
We have a Rails application that is the API component running on api.domain.com and a front-end application in Ember.js running on www.domain.com.
When Ember.js sends a POST request to a route in the API, /events, we want the API to set a cookie to remember a unique user identifier.
Hence this method in the Events controller:
def set_tracking_cookie
cookies[:our_company_distinct] = {
value: create_identifier,
expires: 1.year.from_now,
domain: :all
}
end
As you see, the cookie is set on the entire domain, and is set to expire in a year.
The point is that the next time Ember queries the API, it will be able to read this cookie. However, this is not the case.
Each time the front-end queries the API, the API is unable to find the cookie, nor does it show in the cookies in my developer tools.
The Ember requests set the Access-Control-Allow-Credentials header to true, and I can confirm that the cookie is indeed sent in the response from the API with the correct values for domain, name, path, expiry, etc.
Am I missing something?
Thanks!
For anyone else going through a problem sending/receiving cookies in this way, here are some things I found helpful when I was debugging and ultimately fixed the problem:
When you use the Chrome's (or any other browser's) devtools, examine each request and check it to see if the cookie is being sent from the API on the request where you expect it to be sent, and if all subsequent requests from Ember (or whatever other JS framework for that matter) send this request. In Chrome, go to "Network > [request] > Cookies". Ensure that the front end is sending the cookie properly and that it indeed receives it properly.
We found that this was the best way of adding support for the CORS cookies to Ember was to be done like so: http://discuss.emberjs.com/t/ember-data-and-cors/3690
I'm confused as to what this setting actually does.
According to MSDN, "Gets or sets a value indicating whether the support for the browser's HttpOnly cookie is enabled."
But I'm struggling to understand what this actually means.
The problem I am having is that in my MVC application, the session cookie is not being sent with the secure flag. I've put the RequireSSL="True" attribute in both forms and cookies sections of the web config, but the session ID cookie is still not sent under SSL. I was wondering if this other attribute was connected with it.
If you've implemented requireSSL="true", your cookies should only be transmitted over the HTTPS protocol. Nothing more should be required for that. The HttpOnly flag tells the browser that the cookie should only be accessed by the server -- not by any client-side script. This prevents certain XSS attacks in modern browsers that respect this flag (should be pretty much all at this point).
I need to make an HTTP POST request from outside the browser, but the Rails back-end is not accepting the authentication (error 401). I know I need to pass a CSRF token in such cases, but it's not working.
When I make the request through a form on a browser, it works as expected, but when I try to simulate an identical request (in terms of headers and cookies) from outside the browser (using curl, for example), the authentication doesn't work.
Two small changes allowed me success without a browser: (1) turning off protect_from_forgery, which validates the CSRF or (2) using GET instead of POST for the request. In both cases, passing the cookie is enough. That means the problem is definitely related to CSRF stuff.
So, my question is: how can I make a CSRF-protected HTTP POST to a Rails server without using a browser?
To clarify, the process is broken in three steps:
Login: returns a cookie to identify the session;
New: a GET request that returns the CSRF token to be used later (uses the cookie);
Create: a POST request that submits the information I want to create (uses both the session cookie and the CSRF token).
The only step which fails is the third one.
Assuming your CSRF token is cookie-based, then the program you use to make your requests needs to track cookies. Check out the --cookie-jar option in curl.
I'm an old hand at C but a raw newbie at Java/Tomcat.
I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.
I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.
But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.
Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?
Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?
I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.
thanks for any help,
Steven.
It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.
Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.
It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.
This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).