@eprodromou welp! that explains why none of the REST APIs you looked at use CSRF tokens. 😀
technically you don't need CSRF tokens with a REST API (assuming you are using JSON or XML) because the write request is no longer a simple request and therefore will trigger a preflight request. Since that preflight request would fail on a cross-origin request, then there isn't a way to send the data.
To be clear, my previous comment applied only to oAuth 1, oAuth2 is a really different protocol (its not really the next version so much as two totally different protocols). It sounds likely that oAuth2 would be more applicable, but im not as familar with it as oauth1, so i wouldnt want to comment without reading through the spec to refresh my memory
Here are some thoughts I have...
- It doesn't really matter what the private API does. I suppose this is a question if we can make such a distinction or not. Are all our APIs "public" or are some of them "private" (private as in, limited to the current origin)?
- An option could be.. if a CSRF token is provided, then load the session from the cookie. In this way it's 100% required, but if it's missing (which would be the case for public requests... then that is fine, the cookie is ignored).
- If you have to pass a token for each request.... why look at the Cookies/Session at all? Why not just have a "token" (a JWT or whatever) that contains everything needed to authorize the user?
- Taking this yet another step further... why not embed a client id and secret on the page... and authorize with OAuth 2 like everyone else?
- @Bawolff see https://www.oauth.com/oauth2-servers/single-page-apps/ for how OAuth 2 can be accomplished without a server or an app secret. Effectively it relies on HTTPS (and the server) giving the client id and secret to only the registered app domain. In this way, unless the app gives away the client secret (or the client does) requests from that client id and secret are known to come only from that application. I'm not sure if this can be accomplished with OAuth 1.0 as it does not require HTTPS (afaik).
Sat, Nov 9
Removing campsite as this is not something the team will work on without further thought and discussion.
Fri, Nov 8
@dmaza After the server returns a 301/302 and the page gets redirected... why doesn't the next request (that results in a 200) have the cookies?
Thu, Nov 7
@eprodromou any update on this?
This isn't very difficult to add, but wouldn't it have security implications? (i.e. wouldn't it reduce the anonymity of the user?)
Note that RawAction is not a blockable action (requiresUnblock returns false).
Wed, Nov 6
I'm happy to review if I know how to replicate and what the solution should look like, but right now the description is not clear enough for me to help with that!
Tue, Nov 5
Mon, Nov 4
Fri, Nov 1
Wed, Oct 30
I think this is probably the simplest way to go:
Provide HTML in the blockinfo API responses or have a way for clients to render these blocks.
I think this might be a duplicate of T191939
I would assume that running in the client would defeat the purpose of storing such information trustfully.
On the other hand, I assume we would soon hit any rate-limiting google has on that API if we just run it from production (all requests will be coming from 2 IPs). We will need to tune the concurrency of such jobs, and also add a rate-limiting of sorts in change-propagation I guess.
As far as UX is concerned...
Tue, Oct 29
I would say so! :)
Mon, Oct 28
Thanks for your reply! I don't even understand my own question anymore, but I appreciate your response. :)
For an example of what @Simetrical is saying... see: https://symfony.com/doc/current/service_container/request.html I'm not saying that we should necessarily do that or not, just wanted to express that the pattern is not unheard of.
Fri, Oct 25
Here is the query used to generate the statistics:
SELECT cul_type, COUNT(cul_type) AS count FROM cu_log GROUP BY cul_type;
You can just do sql enwiki which will connect you to a slave - in most cases you don't need to specify a replica