I'm developing a Twitter Application on a Web-Page based on #anywhere.
I think of #anywhere as the Twitter version of the Facebook Javascript SDK (maybe that's where I'm wrong).
Anyway, the thing goes like this.
You put "Connect With Twitter" code on your webpage, and if the user is logged in with Twitter and authorizes your application then you can do whatever you want with that.
So if #user_a is logged in with his Twitter account and visits your website, you can do some fancy stuff like showing #user_a followers or tweet to their account or whatever.
The problem develops like this. Suppose that #user_a is alredy logged in into your app, then #user_a logs out of twitter (because it was a public computer :/) and then someone else comes and logs in to Twitter as #user_b. If #user_b goes to your #anywhere web-page IT will see everything as if #user_a is logged in! D:
Twitter says that all that is fine, because everything is based on a cookie AND you should provide a button for the person to log-out of YOUR site from #anywhere. To me that sounds impractical, because if you (user) would want to stop using twitter you just sign out from the webpage and that should be all (like on Facebook); you shouldn't remember, whose sites you already have connected to Twitter, and pay them a visit to sign out from those, just to protect yourself from someone else using your account. And, to make things worse, that cookie could be easily stolen and well you know the rest of the story.
Am I doing something wrong? Am I thinking of the #anywhere API as something different than what it was intended to be?
#anywhere doesn't advertise itself as a SSO so it doesn't need a Single sign-off mechanism. The idea is to use #anywhere to log into other sites at which point it becomes those sites responsibility to handle sessions including when to sign the user out. Just like if a user logs into site a and site b with two different passwords it is their responsibility to sign of each site.
While #anywhere tokens left that are left active can allow follow up users the tokens are only active for a few hours limiting the potential damage.
Related
I am confused with how social oauth works? Lets say i have implemented social oauth login in my project.
user A signed up in my website with Google Oauth. I somehow put that SIGN UP WITH GOOGLE button in my sign up page and then user will click it and will be directed to a link where google will ask to authorize my app or not. If the user A allows, then at first time what information does the google server send to my server. It will send something so that i could save it in my server to know that a user A has been signed up and could give the userA a id to link it to other tables of my database which is in my server (nothing to do with google server). So real question is what will google(or any other service provider like facebook, twitter etc) send me when a new user signed up and when a existing user signed in again. what will happen if a user (already signed up) try to sign up again? or didn't authorize the website again when logging in?
If you want more detailed question, please comment and I will elaborate.
Ok first off lets use a different term than social login. Lets call it third party login and heres why.
Your application has its own login system users can create their accounts on your system by say adding an email address and creating a login name and a password. Now you want to add third party login that being, Facebook, google and twitter login. These are actually third party logins.
What you will actually be doing is linking the users third party social media accounts with your login system. The term often used for this is called account linking.
Lets say user A has created an account in your system already now A has a Facebook account so they would like to link their Facebook account with your login system. So you create a Facebook login button Facebook will return to you an id this often being the id of the user on facebooks system. So when the user logs in using Facebook you get the Facebook id back that you can store on the users account in your system.
Things get a little more confusing if user B wants to login to your system using Google and B does not already have an account in your system
when they login then you will probably get the users id and i think you get their email address back as well so you can use the email address from google so you can create them a actual account on your system and directly link the google login to it automatically.
Its been a while since i have done it but i believe that you get the user id and the email returned to you from third party providers you may want to check thought if memory serves they are not all the same and you may have to make a request to get the email address after you get the id back.
Social login is still not normalized. You have to work them out one by one unless you leverage something that do it for you like the trusstee.io solution.
It appears to be simple to use and is described here https://medium.com/me/stats/post/ef5d5a5a3943.
I am working on one application which require Facebook Login.
I went through various blog and it is clear how to implement facebook or any other third party login. However just bit confused regarding login persistence/ Or process when user comes to website second time.
What i need is
User come on website and can choose wether he want to register or want to login with facebook.
Once he log in with facebbook i need some additional information from him and i will store that information along with his userid in the database.
If he log off, and comes again to website he will again provide his facebook login details.
once he do that i will get his facebook user id and with the help of that i can create a session easily.
BUT not in case he is already logged in from facebook in the browser and if he try to browse my website, then i have to redirect him to authorized page directly. In that case i have to implement a solution which will take care of this issue. While searching i found one blog which might be the way how to implement it. Facebook Login Filter
But is there any other way i can achive it?
I have an existing rails app which uses 'devise' for authentication.
I would like user's to be able to link their twitter and facebook accounts to their account on my site, so that my application can post updates on their behalf.
Ideally:
When registering, you can choose to set up a standard account, or use twitter, Facebook, etc credentials.
If user chooses to use facebook credentials, I would still like them to be able to link their twitter account, so that my application can post to both at same time on their behalf.
A bonus would be allowing them to have identities which they could link twitter account A to one identity, then switch identities and use another twitter acccount.
My questions are:
if they use a standard account, and link facebook and twitter, are they going to be prompted to enter those credentials every time I post on their behalf? Or does omniauth give me an infinitely valid token?
I know devise can handle omniauth, but I can't seem to tell if it can handle what I am asking. It seems that it's omniauth support is more along the lines of just authenticating site users against twitter credentials not for linking multiples.
is there a rails gem that does this, and is well supported? I see socialite is no longer supported, but it seemed to be a one or the other type deal, not what I want anyway.
because I am already doing standard auth with devise, would it be simpler to just force users to create a standard account, and then use the twitter and facebook api's directly on top of that?
Looking for the best strategy here for doing what I want.
*note: If you think I can get 75% of what I want for 25% of the effort that all my goals would be, let me know. *
Thanks,
~S
My plan for this web app is that it needs the user to log in with LinkedIn, and the user's id on the site and database is their LinkedIn id.
So, the most convenient and elegant thing would seem to be to have no "native" login at all, and just have the user log in with LinkedIn from the start.
Having seen recent disaster for Twitter api developers, I now wonder if this is considered too risky. I am assuming that it is allowed by LinkedIn (haven't checked that yet).
Alternatives could be:
native login then login with LinkedIn after that.
OpenId login and then login LinkedIn after that.
Somehow have a backup login incase linkedin kicks me off.
Any thoughts on the main idea or alternatives? Any other ideas?
As soon as you require a user to create a native login, you're making the usability of your app more challenging IMO. I hate, hate, hate it when I'm forced to create a new account on a site when a single button press would work.
Of course, usability would be at near zero in the unlikely circumstance that LinkedIn's provider no longer works for your app. So, there are tradeoffs.
Does LinkedIn provide access to the user's e-mail address when you authorize them? If that's the case, you could just login with LinkedIn. If LinkedIn's provider no longer works for your app, you could send users an email with a temporary password in an authoritative way. If they don't provide an e-mail address via their provider, then you'll be forced to collect it separately directly from the user (and potentially verify it in case the user made a typo or something).
I've got a company web app. I have integrated it without much problems with Twitter.
This means, when a staff of our company creates a new product, it posts onto the company's profile on the Twitter web site as well.
However, Facebook is another story. Facebook encourages registrants to sign up as "individuals".
For example, on the registration page:
You are not allowed to put generic emails such as (support#company_email.com, sales#company_email.com)
You may not have the first and last name as a company entity. For example Foo Distribution or Foo Inc
Their automated system simply rejects any clever attempts to register as a "non-individual". With Twitter, it was a breeze. Since Twitter allows / encourages companies to register an account with them directly, and not as individuals.
Moving along on Facebook, I found out that I can create a 'page'. Which I can use for the company. It has the option of allowing other "individuals" to be admin of the page. However, this would mean that each staff would need a Facebook account.
I don't really like this approach, since some of our staff may be negligent with their Facebook passwords. I rather have our web app have one 'method' of accessing Facebook's API isntead, the way it is done with Twitter.
How else would you go about this?
I'd make yourself the admin of the page, install an app that you develop, and then let your users make posts to the page through that app. This way, you're controlling access to the page while letting your users still have access to it.
You'll need to use an offline_access-enabled access token for this to work continuously (permissions documentation), and if that token changes, you'll have to log in yourself and refresh that token (it can change when you change your password or uninstall/reinstall the app). Additionally you'll need a manage_pages permission, and you'll need to use the access_token for your page that you can find in /me/accounts to make posts to the page.