I am a hobby web developer running a website for my local concert band. The website has a public part and an internal part. Currently the internal part of the website is protected by a common username/password. In addition to the website, we have a closed Facebook group for all our active members. It is the members in this group who should have access to the internal part of the website, and we regularly get new members and lose old ones (thus the wish for moving away from common username/password). I would like to switch to Facebook login for the website (for control over who gets access, plus people won't have to remember personal usernames/passwords), and I have two specific questions in this regard. Keep in mind that I am completely new to Facebook login, oauth etc.
Is it possible to use membership status in said Facebook group to decide who gets access to the (internal part of the) website? How would I go about doing this?
If not, is it possible to directly specify which Facebook users will have access to the (internal part of the) website? How?
Related
I've come on to help a company out at the last minute after a developer bailed, and I'm left with some annoying quirks. I'm also very green when it comes to Facebook API. I don't have all the history, but here are the facts as I know them:
I've got a Facebook application that is used by a single Facebook account. This Facebook application reads public content of various pages (pages of clients, to be more specific) on Facebook (specifically follower and like counts). Periodically on a web server, we get these numbers and update our records for said clients.
Now, this application has executed fine for months. For security reasons, we changed the password for the Facebook account associated with this Facebook app. After recreating the access token, I started getting the following error:
To use 'Page Public Content Access', your use of this endpoint must be reviewed and approved by Facebook. To submit this 'Page Public Content Access' feature for review please read our documentation on reviewable features: https://developers.facebook.com/docs/apps/review.
My question is, why now? Why did a password reset cause this? Was this app originally grandfathered into not needing to be approved, and now that a password has been reset the app needs to be reviewed? In looking at the app's permissions it does seem it wasn't approved for this feature.
The reason I'm asking is if there's some other reason why this restriction was suddenly added, I'd like to know. Perhaps it's only applicable for certain scenarios and by updating the access token I inadvertently requested some feature the previous app never did?
Thanks.
There is no way to access public pages you do not own without getting "Page Public Content Access" approved now, this was changed a while ago already. So you are probably right, it may have worked only because of the old Token.
There are two ways to solve this:
Get Page Public Content Access approved by Facebook
Use a Page Token for all the Pages - you can only get it by having a role in the Page
I would like to access other users public data to show in my website when they configure the page by their username/id.
It means I will create an app on FB/Instagram side and with the help of this app's access token I would like to fetch public data of other user.
Is this scenario valid now? Earlier it was possible but I am not sure now with changes in policies. Even the documents are not clear enough which can say it's possible or not?
Has anyone tried this out recently?
Users: Only data of users who specifically authorized your App is available, depending on the authorized permissions. It does not matter if data of user profiles is public or not, you have to get permission from each user separately.
Pages: If you want to get data of pages you don´t own, you have to go through a review process with your App to get access to "Page Public Content": https://developers.facebook.com/docs/apps/review/feature/#reference-PAGES_ACCESS
That´s for Facebook, about Instagram you can just hit the docs (as well): https://developers.facebook.com/docs/instagram-api/business-discovery
My number one recommendation, in this case, is Facebook API or Instagram API from Data365. I may be considered biased since it is the tool I work for, but it is really a reliable tool you can get public profile data by users ID or username.
Of course, you can use the official Facebook/Instagram APIs for searching all public objects (post, user, page, event, group, place, check-in). But note, the official API has a number of restrictions. Andyrandy has already described them in his answer. Compared with official APIs, we do not have such restrictions.
Besides, our APIs provide such unique features as gender and age recognition (via face photos) along with identification of post reactions that give a competitive advantage in obtained analytics. Data365 APIs also enable developers to create monitoring tasks for a one-time or auto data update. And above all, we do not break the law but only provide web scraping within the legal framework.
I worked with facebook graph API.
With a Facebook application I was able to retrieve user information (e.g. posts, status update, and so on) using graph APIs. Of course, it can be possible only for users that accept to share their information with the application.
I'm going to do the same with Google+. First of all I want to say that I'm new in the google+ universe.
Reading Google+ documentation I'm aware about the possibility to fetch public posts using something described here:
https://developers.google.com/+/api/latest/activities/search?hl=en
Of course, here they talk only about "public activities".
Does exist on Google+ a similar mechanism to Facebook application that allows me to retrieve private posts from a user (after that he approves my application of course)?
This is not currently available.
You may wish to star (and thus follow) this issue to indicate you would like to see this as a feature and to track progress or responses from Google.
If you clear your cookies and go to quora.com, suddenly you are logged in to quora. How does quora do that?
You can try that yourself. Does site now can check if a visitor is logged in to facebook and act appropiately?
The Quora home page actually has multiple cookie variables. Please analyze the scripting code below:
You will find that there are actually three object classes within the initial script load that will check whether you are logged into Quora or a partner site of Quora's which you have indicated that you will allow the associated login as your proxy login for Quora.
Quora also maintains session data via an internal Session_Table which will keep you "logged-in" to the Quora system unless you specifically "log-out".
The detail logs the IP Address along with Geography, as well as specific browser detail and is pushed through the HTML on Log-Out.
This functionality is not dissimilar to the functionality/strategy that Facebook uses and the "more logged-in" functionality that Eric Schmidt had mentioned that Google was looking to pursue some years back; however, with the exception of GMAIL there still hasn't been a socially interactive app that Google has unveiled that would make people WANT to access again and again without re-login.
I am new to this but I will try my best to explain what I am trying to do.
I have a catalog of products and various private information that my users want to be able to access via their website.
For example:
User-a has an e-commerce site and they want to sell my merchandise. They will be able to access a certain products details via a web service. They will also be able to see the negotiated rate that I've given them along with some other private details.
How should the API handle authenticating the request that comes from User-a's website?
I've been reading all day about different authentication methods but they all seem to revolve around the idea of a third party accessing specific user information. An example is if you let http://randomtwitterapp.com access your twitter profile. In that case, the third party site must manage multiple different users and auth tokens. In our case, my users website is interacting on behalf of the user. I hope this makes sense.
Let's call user A "Alice" because calling her User-A is cumbersome.
Treat Alice's web site as if it were Alice herself. The special pricing and such IS specific to the web site in question, so have it log into your site. Issue credentials that the person developing that site would use to authenticate with, and then use those credentials to determine the pricing and products you show.
As for actual authentication mechanisms, it really depends on your needs. If all you need to do is serve different data to different people, you could do something as simple as an API token passed in the query string: http://api.example.com/products?key=9af4d8381781baccb0f915e554f8798d
Or if Alice already has a username and password for your site, you could have her use those in her API requests with Basic Auth.
If Alice is going to need to enter her account information on various sites that she doesn't control, then oAuth comes in very handy. With that, you can essentially give her an API key for every site she needs to access your API from. And you give her the ability to delete those API keys and deny those sites access.