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.
Related
I have an app that currently allows users to enter in a company name and we use the LinkedIn API to pull all the public posts that this company has made on LinkedIn.
The new API rollout has occurred and while I have a difficult time finding the information I need in the LinkedIn API docs it seems that no one can access company info for a company they are not an administrator of.
I am not trying to access company info or to change their page or anything like that, I just want a list of their public posts. I don't require my users to sign in and even if I did I doubt most of them are administrators of these company pages. Is this totally no-longer possible with the LinkedIn API?
The new API rules for Company profiles stipulates:
"New requirement for Companies API
All calls to Companies API endpoints will require the authenticated user to be flagged as an administrator of the LinkedIn Company Page that is the target of the API call. You become the administrator of a page when you create it. If the page already exists, you will have to contact the existing administrator to grant admin access to other LinkedIn members.
Your API call will return a 403 Forbidden error if you do not have the appropriate admin permission to interact with the target company."
Link here.
LinkedIn is making things really tough for everyone. You'll need to apply to be a partner, but even in your case, the admin would have to sign in. Effectively, unless you're akin to a Hootsuite that gets the page admin's rights for the sake of publishing, you're not going to be able to do what you were. Bummer.
Currently using the Provisioning API that is being depreciated April 20.
This is the current flow:
user (University Alumni) gets to our site http://alumni.columbia.edu/email
they click on Create My Account
they authenticate through our university WIND system using what we call their UNI
they land on a page mentioning that an email account UNI#caa.columbia.edu is ready to be created. They can pick an alias to UNI. They also need to enter a password to use the Chat and POP-mail features of Gmail.
they confirm the creation of the account. At this point the API is being called using https://www.google.com/a/feeds/, some data (email address, name, id) being saved in our database.
To log in, they come through our site, click on the login button, this will use the SSO and they get logged in.
Based on the flow above, do I need to use OAuth2.0?
Yes, you will need to authenticate with OAuth using the Installed Applications approach to do this. Instead of step 5 the way you currently have it, you'll need to call the API from a process on your server with an account that has (limited) admin credentials that can create the account with the Directory API. To do this, you'll need to persist the OAuth token information that the account will use to connect, and handle the code to refresh the token when it has expired.
The first time you run your code you'll need to manually authenticate that account to get your application the appropriate permissions so that they can be stored.
If you're hoping to not go too crazy with handling the authentication side of things and you're using .Net, I'd recommend checking out my project gShell that acts as a wrapper for the authentication and handles the token storing and refreshing for you. It's still a young project but it should fit your needs. Alternately, feel free to browse the code for an example on what to do.
If you plan on using Python, check out Google Apps Manager by jay0lee which is also a wonderful resource.
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).
Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process.
Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.
Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.
My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??
What are the best practices in such a scenario?
Thanks for any info you can provide.
Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.
You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.