Is it possible to see actual CSRF tokens currently stored in your browser?
I've done some googling and haven't found any information on checking this, or if its possible.
I'm trying to debug login/logout issues with an application. Basically I'm unable to login a second time, if I login then logout (unless i clear the browser cache).
So I'm trying to understand if this may relate to the browser continuing to submit the original CSRF token instead of a new one.
Related
I am trying to retrieve a web auth token for CloudKit using their web services and postMessage API token. According to Apple's documentation, token should be returned as part of "data" object through the message callback, but all I am getting is the ckSession variable. It seems like documentation is wrong, or I am missing something.
Is there any additional API which should be called to retrieve the web auth token after this step? I tried being naive and passed ckSession to record listing APIs but that doesn't seem to work. Also, if I use a different token retrieval method, like custom URL scheme, for example, token gets retrieved correctly. This issue seems to only be related to postMessage option.
"Allowed origins" is set to "all domains" and I'm calling auth API from localhost. I am running Windows 10 and am using Chrome browser (if it means anything here, probably not).
It seems like someone had the same issue a couple of years ago and it was posted on the Apple forums, but it hadn't got much love back then.
Any help would be greatly appreciated. Also, I can provide more information, if needed.
As I understand it, you can only obtain the web auth token (ckWebAuthToken) via the front-end JavaScript API. It should be returned after the user signs in with their Apple ID. You could then POST that value to your back-end app and store it somehow (probably as a session variable).
You can read more about getting the web auth token on this page.
If you have since learned more about solving this and know more than I do, I'm all ears. :)
Likewise, I never managed to intercept the ckWebAuthToken with the postMessage method. I suspect it can be used only with the sign in button generated by setUpAuth in the JS SDK.
So instead I redirected to a page of mine hosted somewhere, where I grabbed the token from the query string and sent it to my host app, all in JavaScript. Clunky but it worked! :)
I am the administrator of a Facebook Page. I am building a web app which, under certain circumstances, will post on Facebook as that Page.
With most APIs, I would just get an API key, and supply that when connecting to the API from my app. But Facebook expects an access token instead of an API key. (Specifically, in this case, it needs a "page access token".)
I am trying to figure out how to get a page access token that will be as permanent as possible.
After jumping through a bunch of esoteric, undocumented hoops (see here and here) in order to get a token that wouldn't expire, I had this working. When I ran the token through Facebook's Access Token Debugger, the "Expires" field read "Never". All was good in the world.
But, the next day, my token became invalid anyway. The Access Token Debugger, and my app's calls to Facebook's PHP SDK, both started returning this error:
Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons.
It seems that a token can become invalid for a variety of reasons (but this article is five years old, so who knows – Facebook changes things every two weeks). I had not changed my password. (I might have logged out of Facebook, though.) Facebook offers no specifics about why this particular token might have become invalid.
I've also seen a few references to a permission called offline_access, but Facebook seems to have removed this.
I suppose my question is twofold:
In general, I've found Facebook token authentication to be incredibly brittle when calling the Facebook API from the server. The token system seems to be designed mainly to allow other users to grant (or revoke) various kinds of account access to my apps. But that's not what I'm doing – I'm trying to get a token that will let me post to a page that I own. And for that scenario, Facebook's aggressive invalidation of tokens becomes a serious liability. I can't launch my app if my access token (and therefore my Facebook integration) could randomly stop working at any moment, requiring me to generate a new token and update the app. This seems absurd. Is there an alternative method of authenticating to Facebook for my purposes?
If a page access token is, in fact, the best way to authenticate my app to Facebook in order to post as my Page: how can I ensure that my token doesn't spontaneously become invalid?
I hate developing for Facebook :/ Thanks for any insight you can offer.
Extended Page Tokens are valid forever. They only get invalidated if you change your password or if you change the App Secret of your App. There´s really no magic in it, checking if the Token is still valid is obviously not a bad idea but that´s up to you. For example, you can send yourself an automated Email when there is an error using the Token, so you can refresh it. But it will really just happen if you change your password.
Links:
https://developers.facebook.com/docs/facebook-login/access-tokens
http://www.devils-heaven.com/facebook-access-tokens/
when I do a get request to
https://graph.facebook.com/[userid]
with the access_token i get all the basic info
but when I do
https://graph.facebook.com/me
with the same token i get an error message: An active access token must be used to query information about the current user
I have tried to under stand what can cause that.
I even tried to token that comes with the signed request
I'm on classic asp, with JSON library, I want the auto to be server side if possible. the FB.api("/me" is working but it is not what i really want to achive
I am pretty sure you don´t have a user access token. Did you login the user? Of course you get the public data of every user with your first link, even without any access token. You can even put it directly in the browser and will get results. But for "/me" you have to authorize the user to your app.
See here: https://developers.facebook.com/docs/howtos/login/server-side-login/
It is the same problem as in the other thread for sure, just a different Programming language.
Remember: If the user did not accept at least the basic permissions in a dialog or redirect, he is not logged in and you will never know anything about him in the app (except for some specifics in tab apps, like language, like-status and stuff).
So I'm building my app around facebook oauth, and was hoping to use the fbsr_ token to identify logged-in users (so that the facebook-js stuff stays in sync with my site).
Unfortunately, it appears that these fbsr_* cookies are set to expire within a day. Which means if the user comes to my site a day later, they have no cookie and are shown a logged-out experience.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring). Is there a reason these cookies don't have a longer expiration so the user stays logged-in seamlessly? Most websites allow you to "remember me" when you log in to avoid constant cookie expirations, so I'd rather not have my facebook-enabled website keep logging me out.
Is there anything I can do about this? I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?). But it seems strange that clientside-oauth would have such a limitation, so I'm hoping I'm missing something.
Is there anything I can do about this?
No, not really.
The only way to determine, if a user is currently logged in to Facebook, is to look at the cookie set for the domain facebook.com.
The JS SDK is capable of doing that, because it runs client-side, and can make a cross-domain request to check if these cookies are set.
But there is no way to check for those cookies server-side from your domain – your server only has access to cookies set for your own domain.
I suspect I can probably switch to serverside-oauth where I manage identity and cookie expiration myself (yes?)
If your set your own cookies on your domain, you are implementing your own login system.
And even if you “fake” the cookies that the JS SDK sets under your domain, it would not bring the same results.
There might be a cookie on your domain, that says, “yes, user XYZ is logged in to Facebook” – but that would not have to be the case. I could have logged out of Facebook in the meantime, and your cookies would not reflect that at all. So whatever you’ll try to do next, like f.e. posting something on my behalf from your app, will most likely fail, because you only think I was still logged in to Facebook, but in reality you do not have a valid access token for me any more, since I am not really logged into Facebook.
The facebook-js then runs, recognizes them, creates the fbsr_* cookie, and gives me a callback. I can choose to do a hard page refresh (rather jarring), or try to do fancy in-place ajax updating (tons of complex code, still slightly jarring).
Those are your only viable options.
I'm writing a Windows Phone 7 app and have gotten Facebook login working using the C# sdk, but logging out has proven interesting. I've read this post:
Cannot Logout of Facebook with Facebook C# SDK
which seems to mirror the FB docs which indicate I should navigate to
https://www.facebook.com/logout.php?next=[redirect_uri]&access_token=[token]
However, that doesn't work and silently redirects me back to the facebook home page.
My best guess at the moment is facebook doesn't like the "next" URI I'm providing. I updated my FB app settings but either they haven't propagated yet, or something else is still not working.
I've seen posts recommending using InternetSetOption, but that API is not available on the phone.
In my application flow, logout leads to navigating to a different silverlight page in my app, so I really don't need the browser redirect for my purpose anyway, so I could just "forget" the access token without actually telling FB to invalidate it, but that seems weak and insecure.
So, while I wait longer to see if the app domain changes propagate across FB's servers and solve the problem I have a different question:
Why should the Facebook APIs care whether I provide "next" or not? Shouldn't I just be able to tell them to invalidate a token and have it happen?
Is there a logic piece I'm missing here?
Thanks!
Update: I wrote an open-source Facebook login/logout control for WP7 that allows this (check the example project). It works by essentially using the web browser control to navigate to the logout page and then submit the logout form by injecting javascript into the web browser control. The idea came from this blog post.
The closest thing would be to revoke the extended permissions by issuing an HTTP DELETE to /me/permissions as documented here. Simply forgetting the auth token isn't a bad option either as the access tokens are generally only good for an hour or two unless you asked for offline_access. And if a user is overly concerned, they can remove your application on their settings page on facebook.com.