4 ms·

Authorization to access resources is a big problem in REST. Round Four seems to be an appropriate approach.

leeoniya 12y ago
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.
- ExpiredLink 12y ago
  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.
  - leeoniya 12y ago
    > 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.
    - ExpiredLink 12y ago
      Is REST context an 'official name'?
      - leeoniya 12y ago
        no, it's probably anti-REST anyhow. http://stackoverflow.com/questions/6068113/do-sessions-really-violate-restfulness 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.
- rdeboo 12y ago
  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.
  - leeoniya 12y ago
    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.
    - icebraining 12y ago
      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 http://en.wikipedia.org/wiki/Server_Name_Indication
      - leeoniya 12y ago
        ah yes, forgot about that :)
  - batbomb 12y ago
    I don't think you understand HTTPS. The URLs are, in fact, encrypted. That's why it's called TLS.
  - tankerdude 12y ago
    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.
deleted 12y ago
[deleted]

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.

ExpiredLink 12y ago
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.
- leeoniya 12y ago
  > 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.
  - ExpiredLink 12y ago
    Is REST context an 'official name'?
    - leeoniya 12y ago
      no, it's probably anti-REST anyhow. http://stackoverflow.com/questions/6068113/do-sessions-really-violate-restfulness 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.
rdeboo 12y ago
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.
- leeoniya 12y ago
  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.
  - icebraining 12y ago
    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 http://en.wikipedia.org/wiki/Server_Name_Indication
    - leeoniya 12y ago
      ah yes, forgot about that :)
- batbomb 12y ago
  I don't think you understand HTTPS. The URLs are, in fact, encrypted. That's why it's called TLS.
- tankerdude 12y ago
  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.

deleted 12y ago

[deleted]