I am a new member of a team at my company reviving a legacy product that had Facebook integration, and we wish to continue developing the Facebook side of things, but we can't seem to find the credentials for logging into the app, or even who has access to it.
The app we are trying to recover is "HaloMobile". One thing to note though is the app name on posts is no longer a link. Does this mean the app has been disabled somehow?
I'm obviously not asking for credentials. At this point I'm just trying to "find" the app and possibly determine who is currently assigned as the administrator role, or what my options are. If there is an email address associated with the app, perhaps we can send a transfer request to that email?
If you could get retrieve two piece of information from your code-base, which are App ID and App Secret then you can retrieve the list of roles assigned in app using the following end point,
https://graph.facebook.com/<App_ID>/roles?access_token=<App_ID>|<App_Secret>
And once you know the role, along with the user Ids of the user assigned to it, you can move forward to recover the App by contacting him.
Also, you might want to give this documentation about Application a look, which lists out various fields you can retrieve for getting the required information to get access to your application back, like user_support_email
https://graph.facebook.com/<App_ID>?
fields=name,description,creator_uid,user_support_email
&access_token=<App_ID>|<App_Secret>
Related
I have an application defined in Okta. Both app and users are assigned to the group, yet when user tries to login he gets access denied: Message contains error: 'access_denied', error_description: 'User is not assigned to the client application.'
When user is assigned to app directly, then it can sign in. But should not it work with the group?
Yes, it should work regardless. Are you able to see the application in the list of assigned for your user, when you check in Okta UI? Maybe the group is large, so it takes time, when you assign a large group to the app. Or when a group is assigned to a lot of apps. But in the end you should be able to see the app in question in the list of apps. If it's the case, then something wrong is happening here. Might worth open a ticket with Okta Support. If you don't see the app there, then you do something wrong
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
Apologies for the general nature of this question. Hoping this doesn't get shot down as "too broad", but oh well, here goes:
I'm writing a React Native app that is purely informational (medical information), with a Rails API for the back-end.
The first main question I have is whether its necessary (or a good idea) to use authentication at all. We don't want the user to have to enter any information to use it (username, password, etc). They should just be able to download the app and jump right in to use it and read the information it provides.
However, I'm thinking that I would at least want the API to only respond to someone hitting it from within the React Native app (or not? Is it considered a normal practice to have an API completely exposed in the case of an app like this which is purely information and doesn't have users, like a website?)
Second - at some point we may want to be able to store some simple preferences for that user (I.E., are they a patient or a doctor, so we can tailor the materials based on that / send them to a different home screen when the open the app). Wondering what strategy someone might use to store simple preferences if the user doesn't ever create an account?
I would at least want the API to only respond to someone hitting it
from within the React Native app.
This probably can't be done, as in a mobile app everyone has access to your client secret and can try to reverse engineer your code.
You could make it more difficult by sending a dynamically generated token to your API on the request, for example, a hash based on a time frame, and check if the hash was sent the correct way. Then, you'd have to obfuscate the code in order to make it difficult for someone to reverse engineer it.
Second - at some point we may want to be able to store some simple
preferences for that user (I.E., are they a patient or a doctor, so we
can tailor the materials based on that / send them to a different home
screen when the open the app). Wondering what strategy someone might
use to store simple preferences if the user doesn't ever create an
account?
If you use a Parse Server instance as your backend, you could benefit from the anonymous user functionality. As you're using a Rails API, you could generate a uuid for each installation of the app and save the preferences on your database based on that uuid. If you don't need those preferences stored on your backend, just store any information you need on the device through any abstraction of AsyncStorage.
I really do not need authentication when it comes down to it - there are no users.
I could verify that the data is coming from my app based on a user agent or a hard coded password. SSL should help keep those secret.
But yeah, there would be nothing preventing someone from disassembling the app and getting that information. Great idea by #felipe-martim about generating a dynamic token.
I really just want to prevent basic abuse, and I could deal with that if it ever happened, or protect myself with something like Rack-attack.
And storing user preferences locally should work just fine for local preferences.
Bottom line is that I'll deal with this if I ever need to / the client budget allows for it!
So, I have my web app connected with Foursquare API up and running. It has it's own secret keys and everything. It listens to the incoming push notifications and trying to react on connected users's checkins. So far so good, however, when I'm trying to post something back on user's checkin via one of these:
checkins/reply
checkins/addpost
checkins/addcomment
I got 403 Forbidden error. I know, that I'm messed up something with OAuth tokens but I'm really stuck here and feel a bit puzzled. I try to summarize what's the current status and what I've tried so far:
I Have the App's: clientId, clientSecret, pushSecret
I also connected the Foursquare Account on which the app is creared into my web App, so I get the accessToken, let's name it: appAccessToken
Users are getting registered to my web app, so I get userAccessToken for one of each.
And here we go:
Trying to reply for a user's checkin fails when I'm using appAccessToken. From what I understand, it's like replying on behalf on my App's account, and since that account isn't on the user's "friend list", I get 403.
On the other hand, I'm able to post reply when I use userAccessToken but then, It looks like the user is commenting itself on their own checkins which dosn't have much sense.
I was even so desperate that tried to use clientSecret but no avail...
Can anyone point me out what am I doing wrong here? From what I understand from the Documentation it is, in fact, possible to reply as an App... The only question is, how? :-)
There's ostensibly no difference between the two "types" of access token you describe: appAccessToken and userAccessToken are really two instances of the same thing (a user's access token), one just happens to be associated with the user account that created the app.
For each check-in you are pushed, you should use that user's access token when making a call to checkins/reply. This will reply to the check-in in the style of our Apps Platform. I think in your second comment, you're using the user's access token to add a post to the check-in, which will make it look like the user is commenting on their own check-in.
I am new to coding for the iphone. I have coded a lsogin page which communicates with my server and checks if the user exists and logs them in if the uername and password are correct.
But how do i know which user has logged in so i know which user profile to retrieve?
Does anyone know any good tutorials or documentation on this please.
You can store any value you get back from the server on the device using several methods. Two that come to mind are.
Store the member information in NSUserDefaults.
Store the member information in shared cookie storage.
I think you should look into proper user session tracking on the iPhone since lack of knowledge here can lead to security holes.