[thelist] Link security and performance

Lee Kowalkowski lee.kowalkowski at googlemail.com
Fri Feb 5 10:04:54 CST 2010

On 5 February 2010 01:40, Bill Moseley <moseley at hank.org> wrote:
> On Thu, Feb 4, 2010 at 3:53 PM, Lee Kowalkowski <
> lee.kowalkowski at googlemail.com> wrote:
>> 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.

What I think I meant was you should adopt a public API mindset and
keep it nice & clean.

> 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.

I think that's neccessary though and you should take the hit.
Assigning temporary URI's that theoretically can be invoked by
unauthorised users and processed successfully sounds like you're
wide-open.  Security through obscurity is seldom considered to be good

> 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.

Still don't like it.  What about timing issues?  All these conditions
are true at the time of rendering the page, things might change in the
0-15 minutes between then and the user invoking the next action.  It
really should all be checked again.

> 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.

I wouldn't use the session like that either!  The more you put into
session memory, the fewer requests you'll be able to handle
concurrently, it's not linearly scalable.  Ideally you want your
system to be scalable in terms of transactions/second, rather than the
number of concurrent users entering the equation.

> 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?

None, your account might not be disabled when you fetched the message,
but what if it is disabled immediately afterwards?  Do the delete
anyway?  Hopefully not!


More information about the thelist mailing list