I would like to gather some feedback on how best to handle access control within a web application that has a requirement for offline use.
The app must have access control via username/password but must be available for offline use. That means that the first time the user logs in, the user must have an internet connection. Once logged in the app will set an acl cookie followed by caching all assets through cache manifest.
Is this a solid approach and what other methods have you used to solve this issue?
Thank you in advance for all your feedback.
Answering quite late but even if you no longer need it someone else will...
Once offline, you need to store all access info on the device. It will be accessible by third parties so there will be a matter of time before someone will have access to all your app content. I explain to clients that once you publish something for offline use, it's there for anyone to see. You can implement some basic login but unless you use an online service, it's not going to be any secure...
Giving that, use local storage to keep track of initial login. Then, refresh it every so often when device goes online.
Related
I'd like to login to a RESTful back-end server written in Laravel5, with the single page front-end application leveraging Polymer's custom element.
In this system, the persistence(CRUD) layer lives in the server. So, authentication should be done at the server in responding to client's api request. When a request is valid, the server returns User object in JSON format including user's role for access control in client.
Here, my questions is how I can keep the session, even when a user refreshes the front-end page? Thanks.
This is an issue beyond Polymer, or even just single page apps. The question is how you keep session information in a browser. With SPAs it is a bit easier, since you can keep authentication tokens in memory, but traditional Web apps have had this issue since the beginning.
You have two things you need to do:
Tokens: You need a user token that indicates that this user is authenticated. You want it to be something that cannot be guessed, else someone can spoof it. So the token better not be "jimsmith" but something more reliable. You have two choices. Either you can have a randomly generated token which the server stores, so that when presented on future requests, it can validate the token. This is how just most session managers work in app servers like nodejs sessions or Jetty session or etc. The alternative is to do something cryptographic so that the server only needs to validate mathematically, not check in a store to see if the token is valid. I did that for node in http://github.com/deitch/cansecurity but there are various options for it.
Storage: You need some way to store the tokens client-side that does not depend on JS memory, since you expect to reload the page.
There are several ways to do client-side storage. The most common by far is cookies. Since the browser stores them without your trying too hard, and presents them whenever you access the domain that the cookie is registered for, it is pretty easy to do. Many client-side and server-side auth libraries are built around them.
An alternative is html5 local storage. Depending on your target browsers and support, you can consider using it.
There also are ways you can play with URL parameters, but then you run the risk of losing it when someone switches pages. It can work, but I tend to avoid that.
I have not seen any components that handle cookies directly, but it shouldn't be too hard to build one.
Here is the gist for cookie management code I use for a recent app. Feel free to wrap it to build a Web component for cookie management.. as long as you share alike!
https://gist.github.com/deitch/dea1a3a752d54dc0d00a
UPDATE:
component.kitchen has a storage component here http://component.kitchen/components/TylerGarlick/core-resource-storage
Simplest way if you use PHP is to keep the user in a PHP session (like a normal non SPA application).
PHP will store the user info on the server, and generate automatically a cookie that the browser will send with any request. With a single server with no load balancing, the session data is local and very fast.
Does anyone know why Box.com make it so hard to generate an authorization code programmatically? I wrote some code to do this through screen-scraping, and then recently this broke because (as far as I can tell) one HTTP request parameter changed from [root_readwrite] to root_readwrite. I was able to fix it reasonably quickly (thank you Fiddler), but why make developers go to this trouble?
Judging by the number of questions on this topic, many developers need to do this, presumably for good reason, and I don't think it can be prevented, so why not just embrace it?
Thanks for listening, Martin
The issue with doing OAuth programmatically is that it would effectively defeat the point of OAuth. Users are supposed to be presented with the Box login page so that they never have to give their username and password directly to your app. This allows users to see what permissions your app has over their account (the scope) and also allows them to revoke your app at any time.
Doing login programmatically means that at some point your app knows the user's password. This requires that the user trusts you to not do anything malicious, which usually isn't feasible unless you're a well-trusted name. The user also has to trust that you handle their credentials correctly and won't use them in an insecure way.
Box wants to encourage developers to do authentication the correct and secure way, and therefore isn't likely to support doing OAuth programmatically. You should really try to perform login the supported way by going through the Box login page.
With HTML5's offline capabilities is it possible to create an app that will persist after the connection is lost and the browser is closed? Specifically, here's what I'd like to do:
Connect to the app while online. Download the entire app including a small database it runs on.
Close the browser and disconnect.
Open the browser again while offline and load the app from the local cache.
Thanks to Mark Pilgrim's excellent book I believe I have an idea of how to accomplish the first step, I'm mainly wondering if the last step is possible. If this is possible, I'm guessing it requires some configuration of the browser. Any settings I should be aware of that aren't obvious?
Thanks very much for any help offered.
The last step should be possible - it just depends on what extent you want to implement it to. To my knowledge it shouldn't require any browser settings. You just have to be aware of the limitations of local storage, which I believe is 5mb max at the moment (for most browsers). Obviously you'd have to perform the checks for such permissions as outlined int the Dive Into Html5 guide you linked.
The quickest and dirtiest way is to simply issue a GET request to your online app. If it responds correctly, then use the online version. If not, use the local cache. Just disguise the timeout/failed response as a 'loading' screen.
Is it possible to access system resources via a web page?
Specifically I would be interested in accessing system calls in order to put the computer into standby or sleep.
At this point, I am language-independent. I would imagine that some sort of special access would need to be granted before anything of this nature occurs. My searches haven't really returned much help, so any suggestions would be great.
Yes, it is possible. See for example the online antiviruses.
I haven't done such thing but java applets can achieve that, also some kind of ActiveX controls. Of course user permission is required.
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.