In my application I allow users to connect their Facebook accounts via oauth for the purpose of posting via our interface. We support both page accounts and regular accounts that simply manage pages.
We also inspect the result of the opengraph API call to get a valid URL to their profile, or page. The primary endpoint we use is https://graph.facebook.com/me (with oauth credentials). For some page-only accounts, the returned object has a 'link' value that, when entered into a web browser, 404s.
The bad URLs I have seen fall into two distinct cases:
The URL can be of the form 'www.facebook.com/{page_id}' which 404s on some pages, but not others.
The URL can be of the form 'www.facebook.com/profile.php?id={user_id}' which more often than not 404s.
The only URL format I have seen that works for all accounts is www.facebook.com/profile.php?id={page_id}. In the first case, we detect that the 'link' field isn't of the proper form (using profile.php?id=...), and construct a URL with the proper structure, and it works.
My next heuristic I'm considering adding is to see if the URL is of the proper form....but uses the {user_id} as the id argument to profile.php, and just construct the URL using the {page_id}. Obviously, this is getting ridiculous.
So, is there a good way to know if an account will give back a link that is invalid? Is this a bug in the API? What is the most reliable way to, given a User on the open graph API, to get a working link to their profile/page?
Using 'www.facebook.com/{page_id}' or 'www.facebook.com/profile.php?id={user_id}' will always work - they are both the same. The only reason you'll see a 404 is if the Page has been unpublished / deleted or if the user has deactivated their account.
Related
While implementing a federated single logout (SLO) in our application using IdentityServer4, I was surprised to see only a single SignOutIFrameUrl property in a LogoutRequest object returned by GetLogoutContextAsync method.
Shouldn't it be a collection of iframe URLs for every registered client? We want to trigger a logout for all clients obviously, so we need to generate an iframe per client resulting in multiple iframes rendered on "logged out" page.
I may be missing something here, as documentation mentions "clients" but then describes only a single SignOutIframeUrl property.
IdentityServer keeps track of the clients that you have actually logged into and returns a list of SignOutIFrameUrl for those clients. If you haven't visited a particular client after single log-on, then it won't be contacted for logout by design during single log out.
Just happened to be looking at this again in a project today and I forgot one detail. The logged out page renders 1 iframe and the URL is the endsessioncallback endpoint, then the page in that iframe renders many iframes, one for each logged in client. So you would not see the list version until you looked at the code to render the inner iframes.
I am new to REST APIs, I am actually not looking for any workarounds, I just need to clear my concept because I know I am missing some very important information which can easily solve my problem.
For E.g I made a small website, let's say using angular.js, where I will list some information or some items.
Consider it as an open website for now, everyone is getting same list. Anyone can come to the page and see the list of items. Simple.
Lets say the URL to this list is
https://www.example.com/api/list/v1
Result returned
1. abc
2. cde
3. efg
4. hij
Perfect!
Now my site got traffic, and I decided to implement user thing on my website, so that every user can only see his own information.
So I changed the rest api url to this:
https://www.example.com/api/list/v1/12345
where 12345 is userid.
The user with the user id came on the website, logged in, and browsed the list, by chance he went to the source of the page, and he found the url to list information.
He copied the url and started to use different user id's, he might get lucky any time.
I am not talking about implementing any type of security up til now, there must be several ways to secure it.
My main concern is that isn't it a large security hole, or we can call it an invitation, for injections?
So I just want to clear my understanding, where I am wrong?
Thanks
This is not some security loophole. This is the way it is supposed to work.
Let's put aside the case of APIs. Consider the simple example::
I have a url: www.example.com/jobs/
This will list all the jobs on my website. No authentication or permission of any sort is required to access this data. I am providing it to every user that visits my website. Now I need a way to figure out if the user visiting my website wants to filter the jobs available on my website. So I provide this option in url kwargs. This will look something like::
www.example.com/jobs/java/
So, now the list will contain the data only for Java jobs. Plain and simple.
Now some day I decide that I will let only the registered users to view Java Jobs. So, I introduce a new check in my View that lets you access the java jobs only if you are logged into my website. Otherwise it redirects you to the login page. Depending on the requirement, you put restrictions on the data being sent to the user.
Same is the case with APIs. If you allow the data to be available to any user that uses the API, there is a flaw with your design and not with the concept of APIs. APIs are just the implementation of your logic.
If you don't want a user with id 12345 to access the data of a user with id 123, you have got to restrict the permissions on the API code. You have got to handle themselves. The API will respond to your code.
Hope this clears out everything.
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+.
I'm allowing users to login to my site with either OpenID, Twitter OAuth or FBConnect. If the user attempts to go to a page that requires them to be logged in, after that user logs in I want to send them BACK to that page. Is there an easy way to accomplish this with all of these or should I simply just write the redirect page to a cookie and upon a successful login send them to that page? I'm using Django so if there are any nice tips or tricks involving that specifically that would be great.
Thanks for the input in advance!
You could thread that parameter (the page they were at) through as a parameter to your return_to. As noted in the spec:
Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not modified by outside parties; such a mechanism can be defined by the RP itself.
For example:
def sendOpenIDCheck(...):
# after getting an AuthRequest from Consumer.begin
return_to = oidutil.appendArgs(return_to,
{'destination_url': that_place_they_tried_to_go})
return redirect(auth_request.redirectURL, realm, return_to))
def handleReturnTo(request):
# after doing Consumer.complete and receiving a SuccessResponse:
return redirect(request.GET['destination_url'])
If there's some other state you need to track (like POST data), or you have an extraordinarily long URL that you can't fit in as a query parameter, or you need to have the destination_url tampered with by the user, you store that information server-side, send the key as a query parameter instead of a URL, and look it up when they get back.
Not very different from storing it in the session, unless the user's got several simultaneous tabs in one session that run in to this, and then having it in the query helps.
Sadly OAuth and OpenID aren't really aware of your app states (while OAuth WRAP can be). So you have to take the following assumption:
The user will complete the sign-in WITHOUT switching tabs/windows or doing other requests on your site.
Then you can do the following:
Once you detect the access of a protected site, store the full query in the session. This won't work at all if it's a POST request, you have to prepare for this problem (show them a warning site with a lik that they must login first).
Store a timestamp of when this request happend.
On your OpenID callback check whether the session variables are set and redirect the user to the stored query. Check the timestamp (don't redirect if the timestamp is older than 5 minutes or so). After that clear both variables from the session.
This will lead to odd behaviour if the user violates against the assumption, but I don't think there is any way you can circumvent that.
I'd like to create a piece of code that can be embedded on many different websites (widget).
Is there any way that my code can identify a user without them logging in? I.e, can I use any of the established identity mechanisms floating around the web to reliably identify them across instances of this widget?
I don't need to (nor should I be able to) tap into any information about this user, just identify them.
The websites will be heterogeneous; there's no guarantee that they will have any common aspects, so the widget code needs to be entirely self contained.
What you want to do is what cookies were invented for. But browsers have gotten wise to people being tracked without their permission, and now limit 3rd party cookies.
The Electronic Frontier Foundation recently put up a proof of concept for uniquely identifying a visitor based on attributes of their browser. It's uses things things like:
User-Agent string
http-accept values
timezone
screen resolution and color depth
the installed plugins
if cookies are enabled
It's not guaranteed to be unique, but my browser certainly is, and it will get you on your way to doing the bad things that people don't like.
OpenID is sort of a SSO for the whole internet, yet they still have to sign in to OpenID. Other than that, I can't think of a solution.
I would suggest Open-ID rather than some workaround like this, but if you don't like that solution you might consider something like this:
You can use a cookie from a single domain, then use that domain to redirect to the correct site adding user-id as a parameter or part of the URL-path
For instance a link to add a personal widget on the foo.com -site, could look something like:
http://bar.com/addwidget1?backtoo=http://foo.com/main/
bar.com would own the cookie, change the user preferences and then add user-id to the back-link before re-directing:
foo.com/user-id/
Issues with this approach includes
You need to rewrite every page dynamicly with the user-id.
It's a bit clumsy I think
You can't fully take advantage of web-caches around the net.
The user might loose their cookie.
Benefits
No login
Since you redirect a lot you get stats on the users movement across your sites.
Sounds like you want to implement a Single Sign On framework. Basically when you first see the user, if you don't know them, you redirect them to the single sign on server. Wich authenticates them and redirects them back to you with a authentication token. You verify the authentication token with a web service call to the SSO server. Ff it is valid then you mark that user as signed on.
EDIT
So thinking about it more and reading tovare's answer and your comments. Why not create some javascript code that works like an google ads? You put the javascript on the page and it does an a request to your central tracking server using a dynamic iframe.
Have your tracking server return an image tag with src of the unique id (its own session id) embedded.
<img src=contentserver.com/track.php?id=12345668>
The content server has a server side script (track.php above) that maps its local session id to the unique id received from the tracking server.
The unique id stays the same across all sites.
Edit2
Instead of using an image, use the javascript trick. The content server just requests a javascript file from the tracking server. but the file is a dynamic one generated on the server side. it returns a generated javascript function called unique_id() it returns the unique id from the tracking server. Call the track.php using ajax to determine if this is a unique user.
Use OpenID, or a simplified variant, with your own site as the identity provider. Redirect the user to your identifier site which sets or checks a cookie, then redirect the user back with the user's identity, which was indicated by the cookie, added as a URL argument.
Your identifier site can be an OpenID identity provider which doesn't require any user interaction to authenticate. The sites which receive this identity are probably not OpenID consumers, since they don't offer the user a choice of providers. You can probably do away with some of the signing required by OpenID if your cookie and identifier are signed.
Facebook provides something similar; a site can find the Facebook identity of a user (assuming the user has one) without any action on the user's part.