Add Expiring Token to Endpoint #41
Conversation
Works like a banking fob. Three codes work: * current * previous * next (this may be overreach) The code regenerates every twelve hours. Allowing for three codes ensures that brid.gy still works as it caches for 24 hours.
This allows breaking out of the checking look to occur earlier
- never use future time, that's dumb - allow previous two to be valid - use logged out uid and token - name the action This more closely emulates how the WP nonce works.
|
Hey @peterwilsoncc thanks for the changes and sorry for the late response (I am a bit busy at the moment) I had a look at your code and was curious if it is also possible to add the feature with native nonces? http://codex.wordpress.org/WordPress_Nonces |
|
|
||
| // plain text header | ||
| header('Content-Type: text/plain; charset=' . get_option('blog_charset')); | ||
|
|
||
| // fail if invalide endpoint | ||
| if ( false == $is_valid ) { | ||
| status_header(400); |
There was a problem hiding this comment.
A 403 would probably be better here, http://httpstatus.es/403, as the server understands the request, but refuses to handle it.
A 400 is more of a generic error where the server don't really understand what the client actually wanted to do: http://httpstatus.es/400
There was a problem hiding this comment.
Y, update will be pushed shortly.
|
All in all: I'm a bit concerned with how a client should be able to know when an endpoint will become invalid. Imaging a big social network implementing WebMentions – you don't want them to fetch a post before every new mention of that post. But how often should it fetch a post? Should it keep going with an endpoint until it receives a 403 and then fetch again? Should there be a cache-header set to the length of time of the token life so the client can check for that to know how long to cache the site? If the cache is set to longer than the token life, can't that make it hard for a well-behaved client to actually receive a new token? So would this effectively make it so that no blog post can be cached for longer than I guess this is more of an IndieWeb / WebMention question than a PR question but still feel it kinds of needs to be addressed. |
|
Thinking about this some more: I would advise against including this as a default in a plugin like this for now – I'm not sure this route is the best way to go down to prevent DDoS attacks and it adds a lot of possibly complexity on the client side when it comes to caching etc which is not in favor of WebMention adoption etc at the moment in my opinion. What I do however think is that it should be easy to dogfeed a mechanism like this so that it can easily be tried out. So I would suggest adding a filter for the value of the Would such a solution work for everyone? I hope I'm not sounding too harsh stumbling in here from nowhere with lots of opinions over a month after the PR was sent in. |
|
Finally have a chance to reply to these. Brid.gy caches end points for up to 24 hours so I am I'm using custom nonces to ensure they expire between 24 & 36 hours, current & two previous ticks. Native nonces expire between 12 & 24 hours and use session data. Line comments I'll answer inline. P |
|
fwiw I just removed this functionality from my own webmention endpoint, as I wasn't seeing any immediate benefit. I think there are likely other better solutions to (D)DOS attacks, and this just feels like an unnecessary complication. |
|
I did the same when re-launching recently, for much the same reason. I'll close this off: conflicts and needs a rethink. |
|
BTW: I changed some hooks and added new ones, to enable these kinds of security features as third party plugins. |
Add a rolling token to the webmention endpoint.
A new token is generated every twelve hours, the current and previous two tokens are valid at any one time.
Native WP nonces are out as they include the session and user IDs.
Fixes #39