I'm making a application for facebook that will be used for academic research. Right now when the user goes to install the application I'll request additional information which is stated in the extended permissions.
I would perfectly understand someone not wanting to give out certain aspects of this information (It's just used to gather statistics about people taking part , education, religion etc.)
Does anyone know the best way to filter the permissions? For instance maybe someone is willing to give their age but not education. Therefore can I remove the education request from my application install request dynamically?
If you want to ask the user for only those permissions that he wants to give, you can take input from him before redirecting to Facebook login. You can generate the url for requesting permissions based on this custom set of permissions using the 'perms' attribute of the <fb:loginbutton /> tag or pass the list of permissions you want to the $facebook->getLoginUrl(array('req_perms' => $perms)) call.
To keep track of permission changes, you can use the realtime updates offered. You can know more about it here.
You certainly could build an up-front permissions matrix that the user could cherry-pick from. And that would probably be the way to do it, since you can't do anything to customize the permission challenge that the Facebook Platform generates.
The trick would be keeping track of which permissions the user granted in the given access token you'll receive from back from the Platform. Especially since users can change the permissions granted to your application w/o visiting the application itself - so you'll want to be hooked in to that info via the Real Time Updates.
Related
So I have a platform that works like this: Users can create accounts by logging in with their Google (I USE AUTH0) and then they can create "Projects" which contain lots of other unimportant stuff regarding my current problem (like todo lists, ability to upload files etc; they can also Edit the project by changing some of it's attributes like name, description, theme and so on). There is a home page where everyone can see each other's projects and access them (but not upload files, change the tasks in the to do lists; this is possible only by the person that owns it).
By using a tool like Burp, people can see the request made from frontend to backend, for example when accessing one of the projects, and modify it on the fly.
This is what it looks like inside Burp when they access one of the projects:
As you can see there is a Get request to /projects/idOfTheProject; they can replace the GET with DELETE for example and they will successfully delete it; they can also see what is sent to the backend when a project is edited (name changed, description, thumbnail picture etc) and change anything they want about it.
How should I prevent this?
What I've looked at so far:
a. JWT - Probably the best fitting for my situation, but required the most work to be done (as I already have my platform almost finished with no such a security measure implemented yet, so I may need to rewrite a lot of things in both backend and frontend)
b. Sending the user's id that initiated the action as well to the backend and verify if it has the necessary privileges - the worst solution as users can access each other's profile and see the id, then just change another field in the request's JSON
c. Have a sort of token for each user and send that instead of the user's id - in this way somebody can't get your token by just looking at the communication between frontend and backend (only if it is using YOUR account). That token should be taken maybe somewhere from the auth0 when they create their account? If they provide something like that; or I can just create it myself and store it alongside the other user variables. You would still see the requests in plain text but even if you modified something you would still have to "guess" the owner's token, which will be impossible.
For frontend I use NextJS and for backend Flask.
Thank you in advance!
The TL;DR is that you don’t. A determined user will always be able to see what requests are being sent out by the code running on their computer and over their network. What you are describing when asking how to prevent people from “sniffing” these requests is security through obscurity, which isn’t actually secure at all.
What you should do instead is have an authorization system on your backend which will check if the current user can perform a given action on a given resource. For example, verifying that a user is an administrator before allowing them to delete a blog post, or making sure that the current user is on the same account as another user before allowing the current user to see details about the other user.
I don't see an easy way to grant permissions to another user. It seems to be quite convoluted at the moment, and I wonder if I'm missing something obvious.
Say I want to invite another user to share a Realm. First I would have to ask the other user for their identification, then I would create the permission object, and then finally I would give the other user the address of my realm.
It would be great if I could share some sort of permission token via text message and let the new user register themselves. I suppose I could do that if I created another "User" which represented the shared group, and merely share this abstract user's credentials. It feels a bit hacky that way, but it seems easier to do.
I was hoping the demo application of the shared drawing environment would hold a clue, but after looking at the source code, it turns out both devices are logged in as the same user.
Am I missing something? Given the demo Draw application, how would one user practically invite a second user to join in their shared drawing environment? It seems like there would have to be a whole set of convoluted permissions and url/identification sharing handshakes.
Thanks for asking the question! Today, you will need to create a shared Realm that all users would input their user IDs into and have access to. This way any user can look up an ID and share access to another Realm.
We realize the limitations and are working on offering a number of improvements. The first is pretty close to what you describe, called a PermissionOffer object where you can inform the Realm Object Server you want to grant access to another user for a given Realm(s). The server will then provide a token you can share via any means with the other user. That user can then use the token to create a PermissionOfferResponse object and accept the access grant. This is coming soon, so stay tuned!
Later, we plan to offer a way to lookup user IDs so you don't have to replicate all of them in a shared Realm (see this issue).
I use the Dropbox Datastore in an app that uses both the iOS and JavaScript SDKs. Aside from the 10MB datastore limit, it works pretty well.
But nearly every support request I get makes me wish I could have access to the user's data for debugging. Being able to see exactly what the user sees helps me to find and fix bugs very quickly.
Is there any way for me to access a user's data without logging into their account? Can I maybe store their access token and gain access to just their Dropbox Datastore data?
This is one of the attractive things about Parse: you can see all user data. While there is a lot of wisdom in sharding user data across Dropbox user accounts, it makes app debugging crazy-hard.
Any ideas? What do you do to get around this?
Dropbox datastores, like files, are considered the user's private data, and as such there isn't a way for an arbitrary party to gain access to said data without some sort of authorization (e.g., access to the account, having the data explicitly shared with them, etc.) Likewise, even the developer of an API app that a user happens to be using doesn't automatically get access to the data.
That said, if, as the developer of the app, you want to troubleshoot using your user's data, the most straightforward method would probably be to get an access token for that app/user pair from the user. That would replicate their setup most accurately. (Unfortunately, the Sync/Datastore SDK doesn't make it easy to extract/insert arbitrary access tokens like that though. So, in that case, this would be a bit of work to build some flow to get an access token, e.g., a small web app, and then some work to read data directly from the API.)
Alternatively, you may want to make it possible for the user to share the datastore with your own account.
In any case, it's very important that the user not be misled or confused as to what is happening or what the developer is requesting. That means being clear with user with regards to what the developer is requesting and what will be done with the data. In addition, apps should provide privacy policies in general.
I'm developing a small CMS in PHP and we're putting on social integration.
The content is changed by a single administrator who as right for publishing news, events and so on...
I'd to add this feature, when the admin publishes something it's already posted on facebook wall. I'm not very familiar with facebook php SDK, and i'm a little bit confused about it.
If (make it an example) 10 different sites are using my CMS, do I have to create 10 different facebook application? (let's assume the 10 websites are all in different domains and servers)
2nd, is there a way for authenticating with just PHP (something like sending username&password directly) so that the user does not need to be logged on facebook?
thanks
You might want to break up your question in to smaller understandable units. Its very difficult to understand what you are driving at.
My understanding of your problem could be minimal, but here goes...
1_ No you do not create 10 different facebook application. Create a single facebook application and make it a service entry point. So that all your cms sites could talk to this one site to interact with facebook. ( A REST service layer).
2_ Facebook api does not support username and password authentication. They only support oauth2.0. Although Oauth is not trivial, but since they have provided library for that, implementing authentication is pretty trivial.
Please read up on http://developers.facebook.com/docs/.
Its really easy and straight forward and well explained.
Your question is so vague and extensive that it cannot be answered well here.
If you experience any specific implementation problems, this is the right place.
However to answer atleast a part of your question:
The most powerful tool when working with facebook applications is the Graph API.
Its principle is very simple. You can do almonst any action on behalf of any user or application. You have to generate a token first that identifies the user and the proper permissions. Those tokens can be made "permanent" so you can do background tasks. Usually they are only active a very short time so you can perform actions while interacting with the user. The process of generating tokens involves the user so that he/she has to confirm the privileges you are asking for.
For websites that publish something automatically you would probably generate a permanent token one time that is active as long as you remove the app in your privacy settings.
Basically yuo can work with any application on any website. There is no limitation. However there are two ways of generating tokens. One involves on an additional request and one is done client side, which is bound to one domain oyu specifiedin your apps settings.
Addendum:
#ArtoAle
you are right about every app beeing assighend to exactly one domain. however once you obtained a valid token it doesnt matter from where or who you use it within the graph api.
let me expalin this a little bit:
it would make no sense since it is you doing the request. there is no such thing as "where the request is coming from". of course there is the "referer" header information, but it can be freely specified and is not used in any context of this.
the domain you enter in your apps settings only restricts where facebook redirects the user to.
why?
this ensures that some bad guy cannot set up a website on any domain and let the user authorize an app and get an access token with YOUR application.
so this setting ensures that the user and the access token are redirected back to YOUR site and not to another bad site.
but there is an alternative. if you use the control flow for desktop applications you don't get an access token right after the user has been redirected back. you get a temporary SESSION-TOKEN that you can EXCCHANGE for an access token. this exchange is done server side over the REST api and requires your application secret. So at this point it is ensured that it is YOU who gets the token.
This method can be done on any domain or in case of desktop applications on no domain at all.
This is a quote from the faceboo docs:
To convert sessions, send a POST
request to
https://graph.facebook.com/oauth/exchange_sessions
with a comma-separated list of
sessions you want to convert:
curl client_id=your_app_id \
-F client_secret=your_app_secret \
-F sessions=2.DbavCpzL6Yc_XGEI0Ip9GA__.3600.1271649600-12345,2.aBdC...
\
https://graph.facebook.com/oauth/exchange_sessions
The response from the request is a
JSON array of OAuth access tokens in
the same order as the sessions given:
[ {
"access_token": "...",
"expires": 1271649600, }, ... ]
However you don't need this method as its a bit more complex. For your use case i would suggest using a central point of authorization.
So you would specify your ONE domain as a redirect url. This domain is than SHARED between your websites. there you can obtain the fully valid access token and seamlessly redirect the user back to your specific project website and pass along the access token.
This way you can use the traditional easy authentication flow that is probably also more future proof.
The fact remains. Once the access token is generated you can perform any action from any domain, there is no difference as ther is literally no "domain" where the request is coming from (see above).
apart from that, if you want some nice javascript features to work - like the comments box or like button, you need to setup up open graph tags correctly.
if you have some implementation problems or as you said "domain errors" please describe them more clearly, include the steps you made and if possible an error message.
Right now when I use Facebook's new OAuth2 system, it tells the user that my app is requesting to "Publish content to your Wall". How do I disable this (for fear of scaring off users), as I don't need this enabled. Possible?
Getting the user to authorize one of the extended permissions for your app is kind of the point behind authenticating. You may want to see if the data you need is exposed without authenticating (if you in fact need data). If you can get the uid you can see what is exposed to everyone, and per the privacy changes, I mean everyone. Until the privacy "fire", there was quite a bit exposed to everyone, now 'everyone' means the least restrictive tier among multiple privacy tiers rather than the happy-go-lucky default.
So really the question is, what permission are you trying to get?
There are a few unknown variables here such as what type of app you are making etc.
Check your code for one of the extended permissions, you are probably sending one of them such as offline_access in your auth call.