Re: [xwiki-devs] [proposal] Add support for secet token verification

[i forgot to send this earlier] I guess it will only work if a single number is valid basically forever. I Request, Response and Session so it could expire on logout. Caleb Unless I'm misunderstanding, how can you protect against any form of replay attack if the token remains the same each time? Protection against replay attacks is why such tokens are usually nonces or "one time pads". More practically, you can use a signed timestamp, in whatever form, e.g. my prior suggestion of crypto-cookes+SSL, or you can add an exrtra prop in core. Either way, both implementations time-out or cannot be reused much because the server encodes a timestamp, and encrypts&signs it with it's own secret key. While you're at it you can also have the server self-sign a bitmap of what privileges are available. On submission/post, only those privileges would be available to the executing code, due to the contents of the token/key/crypto-cookie's "privileges bitmap." The script would be executed in context of (1) validity of overall signature (2) valid signed and non expired timestamp (3) access granted in "privileges bitmap", e.g. programming rights, read-, and write-access to spaces (which can all be enumerated in a long string as bitmap). If the timestamp is expired, you could kick into a part of the app that checks that the user is logged in (in browser) through other means (hopefully uninstrusively) and then issues another token, with fresh timestamp as an automatic resubmission. By uninstrusive, I mean, you want the ticket to only be valid for a few seconds, but the user may take minutes, or hours to hit "submit" and shouldn't need to explicitly re-validate or re-auth with a user/password again (e.g. check for auth in cookie, client-certificate, etc). In any case, any time the server actually accepts a submission, it's because the timestamp on a short lived transaction was valid/signed. Anytime anything of "authority" needs to be performed, it checks the privileges bitmap to see if it was initially allowed-for, by the server, and by the valid code-stream (the one with access to the server key for signing/encrypting the bitmap)... That's a fair set of "checks and balances" against site-hacking. Niels http://nielsmayer.com