Security is hard. When this Geni SDK JavaScript was written in 2011 it probably seemed like a good idea to provide a "status" call that would return an access token if the user had already authorized your app. When we implemented additional protections from cross-site scripting attacks last year, this getStatus call stopped working. Why? Because it was insecure.
There are various technologies intended to protect from cross-site attacks: CORS, Content-Security-Policy, X-Frame-Options, cookie directives, etc. The intent is to prevent a malicious site from making a hidden call to Geni's servers that would include the victim's Geni cookies (and therefore look like it's coming from the logged-in user). Imagine, for example, a POST to https://www.geni.com/account_settings/add_email that adds the hacker's email address to YOUR Geni account, thereby allowing him/her to request a password reset email and then take over your account.
Unfortunately the getStatus call worked in pretty much the same way: the only way it's useful is if Geni's API servers look at your login cookies to determine who you are and whether you've authorized the specified API application. If your application doesn't already have an access token for this user, getStatus was supposed to provide you one. But how? It could only do that if it knows who the user is, and without an access token the only way to know who the user is, is to look at the login cookies. So a malicious web page (and a sufficiently insecure browser) could be used to gain an access token to ANY Geni API application, if the user had already authorized that app. Not good! So getStatus has to be deprecated.
The work-around that Michael Shalom Fagan posted will work, but has the disadvantage of prompting the user to authorize your application every time connect is called, even if they've already authorized it (Michael can you confirm?). This would be disastrous on a traditional site where the user navigates from one page to the next (e.g. a Wordpress site) and the Geni SDK is reinitialized on each page. In that case you can initialize the Geni object with the access token that you previously obtained (and skip the connect call) but then you need to look out for expired access tokens.
We're working on a better solution for this, one in which you can store both the access token and refresh token (in cookies, or post it to a back-end server that you control, or browser local storage) and then the connect call would do everything necessary to do one of the following:
- Use the access token passed to Geni.init() if it's still valid
- Otherwise, use the refresh token passed to Geni.init() (if any)
- Otherwise, prompt the user to authorize your application.
It'll take a few days or maybe a week for us to tweak the code to handle that. I'll post here when it's released but in the meantime, just call connect unless you know you have a valid access token (in which case just pass that to Geni.init(access_token: <some_token>)
