I am thinking of tying in a Facebook JavaScript-based application with an existing website that has it's own user accounts, but have a question about a specific user situation.
The website is run almost 100% of the time from 'shared' computers, like those found in a career center. User A comes to my website, signs into the site and then authorizes the Facebook app, which stores their session in the browser, along with, effectively, signing them into Facebook.com.
User A now leaves my application by signing out of my site - but not closing the browser.
User B arrives, logs into my site with their login, but the Facebook session is still active (due to the browser staying open), so any FB app integrations I've included will show as if it is still user A, correct?
So the question is, what are the recommended ways to deal with this? Two options come to mind:
When the user signs out of my website, I fire an FB.logout call, so that all of the sessions are killed. Pros - I can ensure that user's signing into the site will not have old sessions hanging around. Cons - a user who is returning shortly after leaving will have to re-login to FB as well as my site to see the FB integrations - I'd love to avoid the user ALWAYS having to do two logins. Secondly, forcing the FB.logout when they leave my site kills any active sessions they have at facebook.com, which makes for a bad user experience as they would not 'get' why logging out of my site has anything to do with facebook.com, and will then have to re-signin to facebook.com.
The second option would be that when the user authorizes the FB app, I take their member ID and store that locally and persistently (database). Then, when a user returns to the site and signs in, I check their FB auth status, and if logged in to FB, pull their member ID and check it against the one I have stored locally. If they match, I have the correct user, if not, I do FB.logout and have them sign in to FB. Pros - this should ensure I always have the correct user to the site. Cons - not sure if getting, storing the member ID is feasible.
Any suggestions or pointers to the 'best practice' when it comes to ensuring that the current user is indeed the one associated with the FB account, specifically in this 'shared computing' situation where sessions may overlap?
Thanks
The second option looks to me to be the better choice. You can indeed store the users facebook id. By storing it locally i'm assuming you are talking using a cookie; however storing in a database is just as feasible.
Facebook user id's should be stored with a BIGINT(20) data type - such are the recommendations from facebook.
Taken from the user section of the facebook api refrence :
Looks like they changed their recomendations...
Related
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
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
Does anyone have experience using Selenium to automate testing of a webapp that uses Facebook Connect for user login? Any tips or methods that you recommend?
Depends what you want to do?
Will you be using a real-real Facebook User (which is phone verified by Facebook)?
Safest and most reliable ,but very difficult (impossible) to gather "real" users (phone verified by FB).
In terms of defining aspects of the user/connections details, like education history, work history, name, age etc(specially if you do not have access to all the "real" facebook accounts).
Fake facebook users created for testing the app (not verified by Fb)?
Probably the easiest to setup, as all are fake users, no Phone verification(with FB) required.
But email ids for all users would need to be created.
Even though the connection info can be tailored to your liking. One of the main drawbacks(and it has happened to me), is if Fb detects the user is not legit, FB would freeze all accounts. Which would make all your Fb user specific automated tests all useless in the blink of an eye. And there is not much you can do(Unless you plan to get a brand new phone connection to verify those accounts, no google number, no skype, no ip based phones allowed. FB is very strict with that). Also one number can authorize only 1 account.
Will you be using the Facebook APIs to create Fb test users?
Probably the ideal way (according to FB)to use Facebook connect to test your app. click here for documentation on how to use it.
It may seem straight forward, but it has its downfalls(major ones). Very un-relaible, the API returns an error 10-20% of the time, and extremly slow the other times. No way to retrieve the password of a FB test user if misplaced once. Connection info cannot be easily customized. A fair amount of effort required to set it up something without being sure it work each time.
I have personally opted for the second option. Facebook detects the legitimacy of the user (I guess) based on parallel logins across multiple ips. I have selenium RCs running across various servers, which run these tests in parallel, which could have possibly raised a red flag. So i just schedule these scripts in a more organized manner, so as to avoid login overlaps.
I hope in this long explanation you find your answer. :)
For the perl implementation -
$sel->start();
$sel->open_ok("$URL");
$sel->set_speed("500");
$sel->click_ok("//img[\#alt='Facebook']",'User clicks on Facebook Login');
$sel->wait_for_pop_up_ok("", "30000",'Facebook Login Popup Loading');
$sel->select_pop_up("null");
$sel->type_ok("email", "email\#email.com",'User enters Facebook credentials - Username');
$sel->type_ok("pass", "password",'User enters Facebook credentials - Password');
$sel->key_press("pass", "\\13",'User returns Facebook Login credentials');
$sel->select_window("null");
I'm a person with a non-programming background working on a web application that must store user-generated content and always associate that content with the user who created it. I just had the developer tell me since the application must do this, using Facebook as an alternate login method is pointless because Facebook only let's a third-party web application hang on to Facebook profile information for a certain amount of time, and therefore users who login via Facebook cannot actually contribute content that would remain in the web application's databases.
I'm having trouble swallowing this. I just signed up and logged in to stackoverflow using my Facebook account, and it appears to have generated a site-specific user ID that was automatically associated with my Facebook account - thereby allowing me to save/store content on the site without having to actually create a site-specific profile.
My questions:
Where is the misunderstanding here? To what extent do alternative login options affect the ability of my application, which will consist largely of user-generated content, to store user-generated data and consistently associate it with that user? Appreciate the help!
Alternative login allows users to use an existing account to sign in to multiple websites, without needing to create new passwords. Alternate login using facebook, OpenID, gmail or any other provider doesn't affect the ability of your application to store user generated content.
When a user logs in using a login option for e.g. facebook, user enters the facebook login credential(if he isn't already logged in), facebook generates a authenticated token which is utilised by your application for future use.
In case of alternative logins only the login information (User ID/Password) isn't stored in your application, it totally depends on how you are implementing it in your application. But in any case it doesn't affect your application in saving storing and using the user generated content in your website.
Please refer to this link for more info -
http://openid.net/get-an-openid/what-is-openid/
http://oauth.net/
Hope this helps!