I’ve been playing around with the _facebook REST calls. Consider the following:
curl http://my.server.ip.address:4984/{dbname}/_facebook -H "Content-Type: application/json" -vX POST -d @body.json
And body.json is the following:
{
"access_token": "CAAULMWm0eXYBAFDo4ZBSIWEl0sha5Vx4srQy6HA88ym4NOx56oyG3fE7ehi6jlo71U4msh1ejwcRToScUziBSwkN2JDlfl8dsZAPVzexnZB5I03cH81NTsxgAXKmKzX9q9sgb8bZBaUDxzfMl5b2mqFNJzg8Tdg84nJBMqDXBzKzXCRDoMGVzToOE8hgp62GoY0E94BPOPx2H0UJwNYZBbAvVv6mJPZBAZD",
"email": "notmyaddress@something.com",
"remote_url": "http://totallynotmysite.com"
}
What I have learned, is that as long as the access_token string is valid, this will work. “email” and “remote_url” don’t seem to do anything. In fact, you can leave them out entirely.
Even with a bogus “email”, if the access_token is valid, a _sync:user:60503124651 document is created (the number is the user’s facebook id) and in the document it includes the accurate email address (pulled from facebook). Also a document named _sync:useremail:myactualaddress@correct.com is created with a single object {“username”: “60503124651”}.
When I logout of the app that generated the token, then this POST to /{dbname}/_facebook fails. (which it should, because the token is now dead)
Here are my questions:
- Can any valid access token from any application (e.g. from an app that isn’t mine) successfully login to POST /{dbname}/_facebook?
- If so, how do I allow users who have subscribed (paid for) my app in… and keep users who have not subscribed out?
- Maybe if there was a way to register my Facebook appID(s) in couchbase so that it would only create users for access_tokens that have a corresponding appID embedded in it. Like, put an appID field in the sync_gateway_config file…?
- What was the intention behind including “email” and “remote_url” in the json POST? It was supposed to do something, no?
- What does the “passwordhash_bcrypt” field refer to? (found in the _sync:user:60503124651 document) I can’t imagine that’s my facebook password, but since I never provided a password to the API, what is it?
Kind regards,
David
bump
Can you help me with this @andy @jamiltz or @adamf ?
Hi @dbergan,
Yes I noticed the same behaviour.
@andy wrote a spec for custom auth proxy.
I may be wrong but I think this api spec is also applicable to Twitter login, Google+…
In which case, the Facebook login feature isn’t likely to change much until SG has a feature to support any auth provider.
James
Q1-Can any valid access token from any application (e.g. from an app that isn’t mine) successfully login to POST /{dbname}/_facebook?
A.: Yes, tokens are used for this purpose: provide temporary access to an untrusted party to a specific resource. Make sure you don’t “give it away”, by protecting it with SSL.
Q2 & 3- If so, how do I allow users who have subscribed (paid for) my app in… and keep users who have not subscribed out?
A.: One approach is: you can customise the payload of the token, to include the information your server needs to know what this request is to be granted access to. This is a more ‘stateless’ approach.
However, as far as I understand this is not possible directly with the Sync Gateway’s API integrated Facebook API - you’d need to do custom auth for that.
Another approach is to map the user to what he’s entitled to access in your application layer itself. You can be sure nobody will ‘fake/modify’ the token because doing so would invalidate it against your server (as long as you keep the sign key well hidden/secret).
I’d guess this second approach would be easier to implement in case you’ve already setup your auth system. If not, the following resource might be helpful: link.
Q4- What was the intention behind including “email” and “remote_url” in the json POST? It was supposed to do something, no?
A. Not sure which endpoint are you talking about? This is probably documented.
Q5. - What does the “passwordhash_bcrypt” field refer to?
A. Its common practice not to store/transfer passwords in plain-text. Instead, we hash it so nobody will be able to reverse it, but still it is possible to verify it it’s correct because the function is deterministic given an identical input.
BR!
Adam suggested using the facebook app_secret in the github ticket. I think that makes the most sense.
Reading the github ticket now I understand what you meant: it’s not that you’re concerned to protect what will be done in your server with the token but instead, a protection for couchbase sync gateway itself so that it’s not misused. Good catch!
Right. My OP here was a bit rambling, but when I re-wrote for the ticket my brain had chewed on it enough that I could hone in on the actual scenario that concerned me.
Kind regards,
David