3 ms·
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 outsi
by 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 agoIs REST context an 'official name'?
- leeoniya 12y agono, 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.