Hacker News Reader

Comment by leeoniya | Hacker News Reader

i think round 4 should have been the way to go from the beginning. a cart is not a sub-resource of the user. the user is just the auth-context for accessing the cart resource. it could be implicit and held by a cookie/session or token passed as a query param.

to get a specific other user's cart, you would query GET /users/<user_id>/carts and then a follow-up GET directly to the cart resource

regarding authorization, just pass a session token in the query string if you're against implicit headers/cookies.

View on HN

Isn't passing the session token in the query string insecure?

The payload of the requests will be encrypted (assuming HTTPS), but the urls are not. So I think you're opening the door to session hijacking in this way.

edit: I was wrong about this. The URL will be confidential in transit. Thanks for setting me straight.

I still think it is not a great design, but for different reasons: the url will be visible in your browser history and on the server side in the logs.

Putting keys in query strings does leak information on the server though. Query strings are usually logged with the request in log files so you have to be sure to filter out the specific query string for the session token. That's the security concern that I see, especially if the logs get sent out somewhere/someone else for analysis.

well, you need authentication data in every request, which includes GET/DELETE/HEAD/OPTIONS requests with no payload. so either you use query strings (which suffers from the logging issue) or you use headers/cookies which some people argue isn't "REST"ful.

I don't think you understand HTTPS. The URLs are, in fact, encrypted. That's why it's called TLS.

everything over HTTPS is encrypted except the ip addresses and port #.

hostname is also encrypted (cause it's a header), though your insecure DNS pre-queries will give that away to anyone listening on the wire.

Hostname is not encrypted if you're using SNI[1], and if you're not, you can only connect to IPs that serve a single HTTPS site, so it's not meaningfully hidden anyway.

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

ah yes, forgot about that :)

You need to check all user authorizations for all resources. A potential n x m problem. The proposed solution means that you never give a 'user id' to the outside world. In REST parlance, a user isn't a resource.

> In REST parlance, a user isn't a resource.

this is not necessarily true. if you're managing users, then they are resources like anything else. but users can also act as contexts for operations and access, including auth/prmissions, audit/logging.

when the user is acting as a context, it should be implicit and stored in a session, with an initialized token after login.

Is REST context an 'official name'?

no, it's probably anti-REST anyhow.

http://stackoverflow.com/questions/6068113/do-sessions-reall...

though your sessions do maintain some server context. you cannot let the client decide when to expire a session, for example. pure REST is a pipe dream. there are many things that work sub-optimally if adhering to strict rest as it pertains to http. see the second answer in that thread.

Reply on news.ycombinator.com