[Seaside] URL parameters and seaside's security

[Avi Bryant]

On Aug 4, 2004, at 8:27 AM, Kamil Kukura wrote:

> I'm thinking about security issue of Seaside. If block which didn't 
> register a callback for it cannot be executed, it makes it pretty 
> secure from attacks such as playing with GET/POST arguments. Of 
> course, there must be care given to values being passed into an 
> application.

Yes.  This is similar to object-capabilities security: the callback ids 
are capabilities, and if the app doesn't hand them out there's really 
no way for you to make it do something.  Once the app has handed one 
out, and as long as the capability hasn't been revoked/expired, it 
doesn't perform any further checks - anyone with that key can perform 
the action.  This is potentially dangerous, however (for example, 
someone could inadvertently give out a Seaside URL through a referer 
header), and one thing I've meant to do is provide optional IP-based or 
cookie-based restrictions.

> Btw, when I look to numbers that distinguish links (and input elements 
> and buttons - don't know how do you call them) I see they appear in 
> anchor's HREF in various order. Sometimes the number appears before 
> "_s=...&_k=...", sometimes after and sometimes in the middle. Why is 
> that?

I think they're stored in a Dictionary at some point, and so it's just 
up to the hashing method.  Would it be helpful to have the order be 
more consistent?

Avi