Hello I'm doing a PWA and I use Google spreadsheet to store info and send emails.
When I use the app, in the console shows me the "XHR finished loading" message with an url with json data from my entire sheet.
What I want is that people don't have access to that URL or the JSON data, is this possible? or What should I do so that information is not visible in that way?
if your UI can access a URL, anyone could.
You can protect it though, deepening on your server side capability.
If your server side can authenticate the request to have proper credentials, then the protection can be implemented.
But you can't mask anything from UI to prevent users from seeing it. What goes to browser -> user have visibility. PWA wont change that fact.
Related
Today the Facebook oauth login to my website broke. I fired up the debugger and found that parsing the access token was failing. This appears to be because Facebook changed the format of the oauth response. It used to be CGI parameters:
access_token=EAAFO...cBUZD&token_type=bearer&expires_in=5183996
But all of a sudden it appears to be coming over as JSON:
{"access_token":"EAAFO...cBUZD","token_type":"bearer","expires_in":5183996}
The fix in my code looks pretty simple. I just need to change the parser from a CGI parser to a JSON parser and get the same variable that I'm interested in: access_token.
My question is about versioning of this. I don't like it when my site breaks.
Why did Facebook change this? Is this change documented? Is there some sort of versioning on Oauth that I should be using to prevent breakages like this? How do I get notified of future changes to Oauth by Facebook?
The Facebook API upgrade tool does not list any changes that I need to my app for the latest version of the API. In any case, none of the URLs that I'm using for Oauth appear to have a version number embedded in them:
https://www.facebook.com/dialog/oauth
https://graph.facebook.com/oauth/access_token
As WizKid states, it was announced in Facebook Developers Changelog two years ago under the title "[Oauth Access Token] Format". Facebook does have a tool to try to find things that will break, because of API changes, but it didn't alert this one.
You can put API version numbers into Oauth URLs for Facebook. With version numbers, the flow for Facebook login is:
Redirect the user to https://www.facebook.com/v2.9/dialog/oauth with a bunch of required parameters such as your client id, the list of permissions you are requesting, and a return URL.
Facebook lets the user log in, asks them to accept the permissions you requested, and then redirects them back to your site with a "code" parameter
Server-side you contact https://graph.facebook.com/v2.9/oauth/access_token with that code (and some other stuff) as parameters. Facebook responds with a token
Server-side you contact https:///graph.facebook.com/v2.9/me with that token to request information about the user
This is the process that is pretty much documented here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow
I built a Chrome Extension, where a login form is displayed as a side bar using content scripts injection. I do not want the user to see this login form if the user is already logged in on the website and vice versa if the user logs in on the Chrome Extension and then visits the website, user should automatically log in.
I am returning tokens from the backend when a user successfully logs in.
My question is, what is the best way to store these tokens so both the content scripts in my extension and the website have access to the token to check to see if the user is already logged in.
As far as I understand I have localStorage, ChromeStorage but I do not know if they are shared between the tabs of the browser and the extension.
Any direction is highly appreciated.
Thank you.
If you're returning tokens, a reasonable way to do it would be to inject a content script into pages that match the callback URL containing the token, extract it and save into chrome.storage. It is shared between the content script and all other extension contexts.
Do note: chrome.storage is not exactly secure: it's not encrypted on disk, and can be snooped upon with Dev Tools. Then again, the token is normally stored in the cookie store, which can be likewise examined even without access to the (slightly) more secure password storage.
Perhaps the only more secure way to keep the token in the extension is chrome.identity API, but then you have to login separately, defeating your goal.
I want to develop an app that listens to Box Webhooks events for a file create or upload event, and then reads the content of that newly created/uploaded file.
However, I am not able to do so because as far as I understand I need an access token to be able to read contents of a file, but the Box Webhooks [create/upload] event does not provide me with any access token.
Could you please suggest a way using which I can implement my app?
Webhooks are kinda like a postcard. They only give you the bare minimum of info to tell you what file has changed. They're being sent over the wire to an unauthenticated destination, so when a webhook goes out, it can't have a lot of secret information already in it.
It's up to you to catch that webhook, look at the file-id (and potentially some other info, like the user-id) and know what user to have login and get the additional information.
If your application is server-side, and the users have signed in, then you'll already have their credentials, and you can go get the extra info.
If your application is a mobile app with no server side, then you will have to have the client make the extra API calls to get the details.
I currently have a hangout application and I'd like to add some collaborative functionality to it given the realtime API.
Following the realtime API quickstart guide (adding two text areas and a button to authorize with), I've added the relevant code to the hangout XML module(Is this the correct name for this?)
It looks like, however, whenever I click the "authorize" button from within the google hangout instance, the page might refresh (or something?) and a GET request comes back with a: 400 (Bad Request) response.
Is there something I've overlooked?
Perhaps, some documentation I missed?
Is there a better approach to what I'm trying to accomplish?
EDIT: More information on the GET request and response from chrome's javascript console:
https://015isqam6kq3vfnd0h572bpk4rvnem82-a-hangout-opensocial.googleusercon…dgets/ifr?fileId=0B2FRfMTFpkH0S3RDUlhDMWNsbjQ&userId=103345858281489162915 400 (Bad Request) 015isqam6kq3vfnd0h572bpk4rvnem82-a-hangout-opensocial.googleusercontent.com…ets/ifr?fileId=0B2FRfMTFpkH0S3RDUlhDMWNsbjQ&userId=103345858281489162915:1
The page (where the hangout content should be) then shows:
"Missing or malformed url parameter"
The problem lies in the realtime-client-utils.js that the documentation provides.
The idea with the authorization is that upon authorization, it tries to redirect the page via window.location.href and adds parameters to the end of the URL.
Removing the redirect, setting the parameters in the parameters object manually, and restarting the authorization process fixes the problem.
Either I'm dense, or the docs assume I already know what they're telling me, but I need some clarification on doing authentication for a box.com app. I really don't understand whate's going on. As I read it:
the app running on the user's machine sends a request to Box, including all the little secrets (Which aren't all that secret any more if the user knows how to read the code).
The user is directed to the Box login page, which then sends the user to my server (with no page specified) attaching an authentication code.
The app somehow magically gets that code back from my server and sends a request to Box for the access token.
Box sends the access token to my server?
The app again magically gets the access token from my server and sends its APT requests.
Obviously I got lost somewhere.
And, why do I have to have a server involved in the process? The article on making a JavaScript app refers to a direct request for a token. Is there documentation on that somewhere?
You register your application on Box
After registration you receive clientId and clientSecret once on Box website
You hardcode your credentials somewhere in your application
First time your application needs to access Box API it should redirect user to https://www.box.com/api/oauth2/authorize, specifying your clientId, clientSecret and redirectURI as parameters. About redirectURI see below.
The box.com website opens. User enters his own credentials in the web form on box.com
User allows your application to access his files via API on the box.com website
Box redirects user back to you application using redirectURI specified before. One of the parameters to this request is "code". This is a very short-lived (30 seconds) access code that is only aligable for obtaining real access token.
During next 30 seconds your application should make another call to Box API to next URL: https://www.box.com/api/oauth2/token, specifying the previously obtained code. If everything was correct, your application receives an access_token, a refresh_token and "expires" values.
Now your application can make requests to Box API, specifying access_token every time
access_token expires in number of seconds, specified in "expires" field. It should be about 3600 seconds or 1 hour. Each time your application sees that access_token has expired, it should make another request to Box with the refresh_token and obtain a fresh access_token for another 1 hour.
refresh_token itself expires in 14 days
Note: if you develop a desktop application, then you should open browser for user on the step 4, redirectURI should be something like http://127.0.0.1:8080/Callback and you should run a small webserver just to catch the redirect with the code as in step 7.
Box requires that you specify a redirect_uri in your application's profile, and it must be an HTTPS URL.
As a result, it is not possible to use box with what google's oauth2 documentation calls "Client Side" or "Installed" applications, only "Web Server Applications" are allowed. Web Server applications do not have the secret leaking problem, because only the server knows the secret. You can pass the access token from your server to javascript on the client after
the oauth transaction is complete, if you want the client to make api requests directly.
In your question you are not totally clear in what you are actually trying to produce.
I however suspect that you are trying to write a client application what needs to authenticate to box using the OAUTH2 solution they have delivered in API V2.
If this is for an IPhone for example BOX has a great example of how to handle it.
In a WinForm application you would need to capture the resulting code sent back by box in the browser1.isnavigating event.
Windows console application you register a custom URI registration to collect the code.
Neither of these need to be registered in the API developers Application on box as you would pass the redirect required in the request to box.
If this does not point you in the right direction and your writing a .NET app then post again and I will try to clarify a little more.
Box requires some form user interaction which is short sighted in my opinion but try a web service that simulates a user interaction which then you can save/pass the token to your application to sync up with the Box "Cloud".