Incidentally, the other day reading hacker news I happened upon a similar discussion and article. It might be an interesting lecture to put in perspective our own discussion:
article: http://swaggadocio.com/post/48223179207/why-the-hell-does-your-api-still-use-http-basic-auth discussion: https://news.ycombinator.com/item?id=5569625 ----- Original Message ----- > From: "Vojtech Szocs" <[email protected]> > To: "Oved Ourfalli" <[email protected]> > Cc: "Juan Hernandez" <[email protected]>, "engine-devel" > <[email protected]> > Sent: Wednesday, April 17, 2013 3:08:31 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > Hi Oved, > > >> The only difference would be, when REST API receives the request, it looks > >> for "Prefer:use-jsessionid-header", and if it's present, it uses > >> "JSESSIONID" header value to look up HttpSession in some way (not sure > >> about > >> implementation details, though, but this should be possible to do). > >> > >> So, what do you think? > >> > > As far as I saw, the handling of the cookie is done before the REST code, > > and that's why we need the cookie. > > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > > header, and not the cookie, but I didn't find a way to do that yet. > > I'm also not sure about this, so far I've only found: > http://stackoverflow.com/questions/5807664/tomcat-how-to-access-session-manager-from-servlet > > It seems that the solution is to either provide custom session manager > implementation in JBoss, or to obtain standard session manager early when > processing request and create session manually there. > > Vojtech > > > ----- Original Message ----- > From: "Oved Ourfalli" <[email protected]> > To: "Vojtech Szocs" <[email protected]> > Cc: "Juan Hernandez" <[email protected]>, "engine-devel" > <[email protected]> > Sent: Wednesday, April 17, 2013 12:29:09 PM > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > ----- Original Message ----- > > From: "Vojtech Szocs" <[email protected]> > > To: "Oved Ourfalli" <[email protected]> > > Cc: "Juan Hernandez" <[email protected]>, "engine-devel" > > <[email protected]> > > Sent: Wednesday, April 17, 2013 1:25:06 PM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > Hi Oved, thanks for your feedback! > > > > > We currently return the JSESSIONID also using HTTP headers. We currently > > > return the jsession id also as part of the response HTTP headers, but the > > > client still needs to pass a cookie with the appropriate value in order > > > for the REST session to work. Isn't that enough to cope with this issue? > > > > Right, currently REST API responds with JSESSIONID cookie + separate > > JSESSIONID response header, both carrying session ID value. > > > > As I wrote in my original email: JavaScript running at > > [http://example.com/webapp] *cannot* get/set cookies from requests at > > [http://example.com/restapi] > > > > So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is > > why > > it uses separate JSESSIONID response header in order to *read* the session > > ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on > > standard cookie-handling implemented in browsers: all cookies for location > > X > > [http://example.com/restapi] will be part of any request to location X. So > > it's the browser who sets JSESSIONID cookie for REST API request, not > > WebAdmin. > > > > To answer your question, currently it's enough to work around the cookie > > access limitation, but it's not good enough in my opinion (from > > JavaScript/webapp perspective).. > > > > > If not, then we might be able to do option #2: > > > Today, we keep the engine session ID on the HTTP session attributes. > > > So, we can support either passing the cookie with the JSESSIONID (taking > > > the engine session ID from the http session), or passing the engine > > > session ID as HTTP header (assuming we would also return the engine > > > session ID upon first REST request). > > > > Well, the problem I described only relates to the way how JSESSIONID value > > is > > transmitted between client and server: currently using cookies, so REST API > > client has to do cookie handling. > > > > It would be really great if I could tell REST API to use plain (i.e. *not* > > Set-Cookie & Cookie) HTTP header, for example "JSESSIONID", for the purpose > > of transmitting session ID value between client and server. > > > > For example, the request to acquire session would be: > > > > GET /api HTTP/1.1 > > Host: www.example.org > > Prefer: use-jsessionid-header > > JSESSIONID: xxx > > > > [Feel free to replace "use-jsessionid-header" with anything you like. If > > client doesn't specify "use-jsessionid-header", server expects "Cookie" > > header by default to preserve compatibility.] > > > > And the response would be: > > > > HTTP/1.1 200 OK > > JSESSIONID: xxx > > > > [If client didn't specify "use-jsessionid-header", server would use > > "Set-Cookie" header by default to preserve compatibility.] > > > > > This approach is problematic, as it might work well now, when the only > > > attribute we use is the engine session ID, but in the future that might > > > not be the case. > > > If it is important enough (i.e., you can't really work with option #1) , > > > then we can make a decision to save the attributes on the engine session, > > > rather than on the HTTP session. > > > So, we would start by supporting them both together, adding new > > > attributes > > > only to the engine session, and in the future deprecating the use of > > > cookies, and only supporting HTTP headers. > > > > I think you can keep the current implementation, i.e. use REST API > > HttpSession to store Engine session ID value. > > > > The only difference would be, when REST API receives the request, it looks > > for "Prefer:use-jsessionid-header", and if it's present, it uses > > "JSESSIONID" header value to look up HttpSession in some way (not sure > > about > > implementation details, though, but this should be possible to do). > > > > So, what do you think? > > > As far as I saw, the handling of the cookie is done before the REST code, and > that's why we need the cookie. > Perhaps there is a way to make jboss take the JSESSIONID from the HTTP > header, and not the cookie, but I didn't find a way to do that yet. > > > Vojtech > > > > > > ----- Original Message ----- > > From: "Oved Ourfalli" <[email protected]> > > To: "Vojtech Szocs" <[email protected]> > > Cc: "engine-devel" <[email protected]>, "Juan Hernandez" > > <[email protected]>, "Michael Pasternak" <[email protected]> > > Sent: Wednesday, April 17, 2013 11:13:12 AM > > Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > > > ----- Original Message ----- > > > From: "Vojtech Szocs" <[email protected]> > > > To: "engine-devel" <[email protected]> > > > Sent: Monday, April 15, 2013 2:04:24 PM > > > Subject: [Engine-devel] Proposal to make REST API more webapp-friendly > > > > > > Hi guys, > > > > > > having worked with Engine REST API from web application (JavaScript) > > > perspective, there are things that could be improved to make REST API > > > more > > > webapp-friendly. > > > > > > First of all, webapps are *not* traditional HTTP clients, i.e. they have > > > *not* full control over HTTP processing. There are some standard > > > conventions > > > and behaviors built into web browsers that any REST API implementation > > > should be aware of. > > > > > > -- > > > > > > (1) Don't force clients to use cookies for transmitting authentication > > > information! (or don't use cookies at all) > > > > > > Good explanation can be found at > > > [http://www.berenddeboer.net/rest/cookies.html]. Cookies have many > > > disadvantages: > > > > > > * cookie parsing/formatting is not trivial > > > --> extra complexity imposed on REST clients > > > > > > * in addition to Same-Origin Policy > > > [http://en.wikipedia.org/wiki/Same_origin_policy], cookies can be get/set > > > *only* for the given path > > > --> JavaScript running at [http://example.com/webapp] *cannot* get/set > > > cookies from requests at [http://example.com/restapi] > > > > > > * cookies are the primary source of Cross-Site Request Forgery > > > [http://en.wikipedia.org/wiki/Cross-site_request_forgery] attacks > > > --> malicious websites/scripts can forge requests to REST API that will > > > include the cookie, compromising user session > > > > > > Alternative: clients could be given the *option* to use regular HTTP > > > header > > > for transmitting authentication information. > > > > > > For example, webapp could read such (sensitive information) header, store > > > it > > > securely via HTML5 Session Storage > > > [http://en.wikipedia.org/wiki/Web_storage] and implement related HTTP > > > processing on its own, e.g. pass this header for all authenticated > > > requests > > > (instead of pushing this responsibility to browser). > > > > > > > Option #1: > > We currently return the JSESSIONID also using HTTP headers. We currently > > return the jsession id also as part of the response HTTP headers, but the > > client still needs to pass a cookie with the appropriate value in order for > > the REST session to work. Isn't that enough to cope with this issue? > > > > If not, then we might be able to do option #2: > > Today, we keep the engine session ID on the HTTP session attributes. > > So, we can support either passing the cookie with the JSESSIONID (taking > > the > > engine session ID from the http session), or passing the engine session ID > > as HTTP header (assuming we would also return the engine session ID upon > > first REST request). > > > > This approach is problematic, as it might work well now, when the only > > attribute we use is the engine session ID, but in the future that might not > > be the case. > > If it is important enough (i.e., you can't really work with option #1) , > > then > > we can make a decision to save the attributes on the engine session, rather > > than on the HTTP session. > > So, we would start by supporting them both together, adding new attributes > > only to the engine session, and in the future deprecating the use of > > cookies, and only supporting HTTP headers. > > > > cc-ed Juan and Michael, as they might have some input on that. > > > > > > > -- > > > > > > (2) Straight-forward HTTP Basic Auth has some drawbacks! > > > > > > HTTP Basic Auth > > > [http://en.wikipedia.org/wiki/Basic_access_authentication] > > > over (non-secure) HTTP connection means sending user credentials > > > (username/password/domain) in easy-to-decode cleartext, i.e. the value is > > > *not* encrypted or hashed in any way. Using secure lower-level protocol > > > (SSL) fixes the consequence, rather than the root cause of the > > > confidentiality issue. > > > > > > Furthermore, browsers typically remember HTTP Basic Auth information > > > (either > > > via browser-specific popup, or via XmlHttpRequest) until the browser > > > window > > > is closed. This means the webapp has no control over HTTP Basic Auth > > > header > > > after it has been set! This is the reason why it's hard to implement > > > "logout" functionality in webapps when using HTTP Basic Auth. > > > > > > Last but not least, HTTP Basic Auth is vulnerable to Replay attacks > > > [http://en.wikipedia.org/wiki/Replay_attack]. Someone between client and > > > server can intercept requests and replay them, compromising user session. > > > > > > Alternative: clients could be given the *option* to use more advanced > > > authentication scheme. > > > > > > I've just read an excellent article at > > > [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] > > > which describes easy yet secure authentication scheme inspired by Amazon > > > Web > > > Services REST API authentication > > > [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. > > > The idea is simple: collect auth information, hash (sign) it with a > > > private > > > key, and send everything to server. To guard against Replay attacks, just > > > provide some timestamp to enforce request expiry after some time (say, > > > 5-15 > > > minutes). Easy and simple! > > > > > > -- > > > > > > (3) Support JSON for resource representations! > > > > > > I think this is pretty much obvious. XML has no real advantages over > > > JSON. > > > JSON, on the other hand, has good support in webapps (JavaScript) and > > > maps > > > directly to common data structures (i.e. string, number, boolean, and so > > > on). > > > > > > From webapp perspective, it's much easier and natural to use JSON than to > > > parse/format XML documents. > > > > > > Alternative: clients could be given the *option* to use JSON, in addition > > > to > > > XML representation. > > > > > > -- > > > > > > Vojtech > > > _______________________________________________ > > > Engine-devel mailing list > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
