[thelist] Link security and performance

[Bill Moseley]

On Thu, Feb 4, 2010 at 3:53 PM, Lee Kowalkowski <
lee.kowalkowski at googlemail.com> wrote:

> On 4 February 2010 15:17, Bill Moseley <moseley at hank.org> wrote:
> > In that case I built normal links (with query parameters) but also
> included
> > a hash of the parameters along with their session ID and a secret.  That
> way
> > when I receive the request I can validate that it's not been tampered
> with
> > and it is a valid link created for the specific page.
>
> That does sound like it might work, but doesn't sound necessary.  REST
> APIs don't do this when authentication or authorisation is involved.
>


Not sure I follow -- or we are discussing different things.  But a REST API
request is a good example.

Sure, a DELETE to /message/1234 to delete that message is all that's needed.
 I can look at the session and determine the the user and then I can do a
join in the database to check that message 1234 belongs to the current user
and then test any other permissions to check if deletes are allowed on that
*specific* message.  Assume that's a pretty involved and slow process.

Now, previously, when the user fetched the list of messages (which included
1234) the server has already done the expensive work of determining that
1234 is their message, and also probably determined that the user can delete
it so that a delete button can be provided.  So, at that moment we know 1234
can be deleted.

Later, when the DELETE comes in I can check all that again.  Or the other
option would be to send a token associated with that item on the original
GET so that when the DELETE comes back I also get a token for that item that
tells me it's ok to delete.

True, I could store that message-specific data (ownership, permissions)
server side in session and then when a delete comes in for that item pull
the data from the session.  But, then I have the task of managing a lot of
data in the session which may never get used.

Back to the Gmail example.  I may view hundreds and hundreds of messages
before I actually delete one.  Gmail sent them to me -- it knows I own them
when I first fetched them.  So, for example, say it's expensive to delete a
message because it has to check that the ID I provide is mine, I have access
to the message, my account isn't disabled and so on.  All stuff Gmail knew
when it provided me with the message.  So, what trick can the application
use to not have to do all that work again when a request comes in to delete?

I didn't say that very well, but hopefully you get the idea. ;)



-- 
Bill Moseley
moseley at hank.org