Application, lots of html/js => app.html
If a user is authenticated true OAuth/Google-Drive => Have access
Else its not a logged in user => No access
This could be done server side, but then a OAuth flow would need to be executed on server side and then client side? I could move everything server side but that seems to be a lot of on the app engine resources (eg getFile(), updateFile()) which could be avoided; only client is taking to his own drive right? cut the middle man out.
I my going the right way about this?
If I understand you correctly, yes, this is correct. You can write Google Drive apps completely in the browser.
Why don't you redirect to the actual html page with the GDrive calls after authentication ?
It would go like this : every user lands on the login.html page, which only handles the OAuth part. Once the the OAuth token is retrieved login.html redirects the user to the actual app.html.
More generally though, I cannot see any reason why you would want to hide the code from users who did not authenticate to Drive. Anyway, without an OAuth token this code is useless.
Related
I am a beginner in web development.
I create a project only in HTML, CSS, and Javascript.
My task is to create the login page and main page, but the user can access the main page only when he is logged.
In the backend are database connector scrip, a login script, and script which checking user is logged.
Before the user opens the main page script creates a request and gets a response from the script in this format:
{
"logged": true,
"uid": 123456
}
I parse JSON and if logged is false I redirect to the login page using window.location.replace().
Is this approach prevent from open the main page when the user is not logged?
I am asking because clients can modify Javascript files in a web browser.
I know that it is easier to create this in PHP using the location header and it can't be modified by the client, but I can't make it in this way.
I am asking because clients can modify Javascript files in a web browser.
Not really. But yes, a check such as what you describe is easily circumvented client-side.
The rule is this: Anything that should not be visible to the user if they aren't authorized and authenticated must not be sent to the client at all unless that authentication has been provided. So the request for the "main page" from the server must be allowed or disallowed by the server, and served non-cacheable.
Usually the page itself isn't all that protected, but the information you show on the page is. E.g., the page is the scaffold and layout and such, but the protected information it shows is provided using ajax or similar, and only when the user has been authenticated.
Am trying to make an app that runs both online and offline but i want my user to be authenticated or to be logged in once. So after the initial login i want them not to be able to see the login form again, i want to show them a new part of the app. They should be only to see the login form only when they decide to logout. My problem is that it would have been easier for me to do this if they are always online but they might be offline too so i just need them to login once and next time they boot up the app they wont see the login form again rather they would see something else.
There is no authentication offline. Authentication is made so that the server-side makes sure it is used by a given identity because you can never trust the client-side. If there is no server-side, there is no authentication process.
If you just want to let the user use your application, even though he is online, why don't you store a local copy of the user profile within the local storage after a successful authentication? (with only non critical data of course).
This way, your application can rely on its memory to fetch the user profile and not the server while it is offline.
You could save an kind of "userIsAuthenticated"-Flag to local storage (see https://facebook.github.io/react-native/docs/asyncstorage.html).
Based on this flag you could decide which screen the user see on startup.
But be aware, it could drive your Users crazy, if they have allways to relogin, if the network-connection (maybe cause of bad 3g/4g) was Interrupted.
You also give a notice if a user is offline, that they have to be online to use this app.
BTW: To request if a user has Network-Connection you can use: http://facebook.github.io/react-native/releases/0.48/docs/netinfo.html#netinfo.
Don't forget to set permissions in AndroidManifest.xml to be allowed to use the request.
I have a Facebook app with a page tab installed on many pages.
I know I can parse, server side, the signed_request and have all the data I need on the page, the current user etc.
However, I just need to know the page ID, or even the page URL, using client side JS (so, no access to signed_request which is sent via POST, no PHP or other server side language).
Is there a way to grab that information alone? Even if unsigned and insecure?
I'd really love to know whether it is possible at all before setting up a server side process, however even if the answer is "no, you can't do it" please give some motivation on why the only way to know the current page should be a server side script, what security violations could possibly arise if Facebook was offering a way to know the current page in an insecure way.
The signed_request (http://developers.facebook.com/docs/authentication/signed_request/) is part of the authResponse when calling FB.getLoginStatus() (https://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus/)
{
status: 'connected',
authResponse: {
accessToken: '...',
expiresIn:'...',
signedRequest:'...',
userID:'...'
}
}
And inside the signed Request is the page id.
However, for this to work you will need to authenticate the user to your app. But at least you can do it all client side without any need for server-side scripting. And another really important item to remember is that you'll need your app secret to parse the signed request, and exposing that critically secret item in your client-side could will be extremely risky!
If your requirements say you can neither auth the user nor process the signed request server-side, then you won't be able to get the page id client side.
For security's sake, process the signed_request server-side. :)
Happy coding!
Using window.top.location you can get the complete URL of the page tab. You can then parse the ID from there!
I have two web pages that I am trying to send information between. One is the login page that takes in the users information and calls a web-service to determine if the user is authenticated. Upon ensuring authentication I want to redirect to my other web page with some way of telling that the user has logged in and is authenticated.
I know that javascript has window.location = url but this does not forward the authentication header or anything else as far as I know. Is there a way to redirect with authentication headers or other way to tell the user is authenticated?
Thanks for any help.
There is not a standard method for doing that since javascript is a client side language but you have some alternative low-security solutions.Sessions are not necessary to function a client side language also for the better security you better stick to PHP or some other server side language.Because javascript can be easily skipped and it might put you in a trouble.
Just use your authenticated language for session and header functions also.
Hope this helped,
Regards.
According to the Facebook API documentation, most of the work is handled through javascript.
That means that all the processing is done, and then the front end checks if the user is connected to Facebook/authorized. right?
My question is:
Suppose a user goes to my site for the first time ever.
He clicks on "facebook connect". The javascript verifies him as authentic, and it "redirects" to another page on my server. From then on, how do I know that the user is actually authenticated to my website, since everything is done on frontend?
I think this is correct, but aren't there some security issues..:
-After user clicks Login, Facebook redirects to a page on my site. AND they also create a cookie with a specific "Facebook ID" that is retrieved only from this user. My backened will "read" the cookie and grab that ID...and then associate it to my userID.
If that is correct...then it doesn't make sense. What if people steal other people's "facebook ID" and then forge the cookie? And then my backend sees the cookie and thinks it's the real user...?
Am I confused? If I am confused, please help me re-organize and tell me how it's like.
Facebook Connect uses a clever (or insane, depending on your point of view) hack to achieve cross-site communication between your site and Facebook's authentication system from within the browser.
The way it works is as follows:
Your site includes a very simple static HTML file, known as the cross-domain communications channel. This file is called xd_receiver.htm in the FB docs, but it can be named anything you like.
Your site's login page includes a reference to the Javascript library hosted on Facebook's server.
When a user logs in via the "Connect" button, it calls a function in Facebook's JS API which pops up a login dialog. This login box has an invisible iframe in which the cross-domain communications file is loaded.
The user fills out the form and submits it, posting the form to Facebook.
Facebook checks the login. If it's successful, it communicates this to your site. Here's where that cross-domain stuff comes in:
Because of cross-domain security policies, Facebook's login window can not inspect the DOM tree for documents hosted on your server. But the login window can update the src element of any iframe within it, and this is used to communicate with the cross-domain communications file hosted on your page.
When the cross-domain communications file receives a communication indicating that the login was successful, it uses Javascript to set some cookies containing the user's ID and session. Since this file lives on your server, those cookies have your domain and your backend can receive them.
Any further communication in Facebook's direction can be accomplished by inserting another nested iframe in the other iframe -- this second-level iframe lives on Facebook's server instead of yours.
The cookies are secure (in theory) because the data is signed with the secret key that Facebook generated for you when you signed up for the developer program. The JS library uses your public key (the "API key") to validate the cookies.
Theoretically, Facebook's Javascript library handles this all automatically once you've set everything up. In practice, I've found it doesn't always work exactly smoothly.
For a more detailed explanation of the mechanics of cross-domain communication using iframes, see this article from MSDN.
Please someone correct me if I'm wrong - as I am also trying to figure all this stuff out myself. My understanding with the security of the cookies is that there is also a cookie which is a special signature cookie. This cookie is created by combining the data of the other cookies, adding your application secret that only you and FB know, and the result MD5-Hashed. You can then test this hash server-side, which could not easily be duplicated by a hacker, to make sure the data can be trusted as coming from FB.
A more charming explaination can be found here - scroll about halfway down the page.
Same issues here, and I think Scott is closer to the solution.
Also Im using "http://developers.facebook.com/docs/?u=facebook.jslib-alpha.FB.init" there open source js framework. So things are a little different.
For me, via the opensource js framework, facebook provides and sets a session on my site with a signature. So what I am thinking is to recreate that signature on my side. - if they both match then the user is who he says he is.
So basically if a user wanted to save something to my database, grab the session signature set up by facebook and recreate that signature with php and validate it against the one facebook gave me?
if($_SESSION['facebookSignature'] == reGeneratedSignature){
// save to database
}else{
// go away I don't trust you
}
But how do you regenerate that signature? preferably without making more calls to Facebook?