CODEWITHSUNDEEP
javascriptajaxauthenticationdojo
andreb
andreb

Reputation: 63

dojo web application authentication

I am attempting to develop a pure javascript web application using Dojo. The problem I face is one of restricting access to portions of the application. Authenticated users should be able to access everything, whereas non authenticated users should only be able to access a login screen.

The issue is that nothing (that I am aware of) will stop a user from opening up a browser javascript terminal and entering something like: app.displayRestrictedContent(); and thus gaining access to a screen intended for authenticated users.

I have implemented an ajax based login; all ajax calls are secured with a session. So while the non-authenticated user can load a restricted screen, they wont be able to fetch data for it. But still, It seems wrong for this screen to be arbitrarily accessible.

Am I trying to do the impossible? It seems silly to write code such as if (user.auth) app.displayRestrictedContent(); when it's so easily circumvented. And this leads me to believe I am missing something rather obvious to everybody else. I can't find much information at all on pure javascript based apps and authentication models.

Upvotes: 5

Views: 2319

Answers (3)

Anh Pham
Anh Pham

Reputation: 5481

But still, It seems wrong for this screen to be arbitrarily accessible.

Because it's client-side code. Anything you write in js, or get compiled to js, expect it to be readable by the users.

Am I trying to do the impossible?

you can dynamically load js modules after the user authenticates. So at first, just load 1 login module. When the user logins, if successful, the server return a list of js modules to load, if not, return empty list. It also helps improve load time when the users come to your website.

Upvotes: 2

Frode
Frode

Reputation: 5710

I'm by no means an expert, but here are some thoughts I've made on this. I don't think you've missed anything (if so, I have too) - I think this is a pretty fundamental issue with all client applications, whether it's a compiled executable or a Javascript.

Of course, the compiled executable is not particularly hampered by it, because it's been made into machine code which is very difficult to read or decompile into anything useful. With Javascript however, the application is often served exactly as you wrote it, and so it's easy to modify and reason about.

That brings me to the first semi-solution: obfuscating your Javascript. If you use Dojo's build tool with the shrinksafe parameter, all unnecessary whitespace is removed and all identifiers are shortened, making the code quite difficult to read. I called this a semi-solution, some may say even that is giving it too much credit - I myself still think it's worth doing. After all, the shrunk code downloads faster too!

The second measure I take in my apps is to separate the different parts into "build layers". For example, in my build profile, I'll have something like

dependencies = {
    ..
    layers: [
        { name: "../myApp/Core.js", resourceName: "myApp.Core",
          dependencies: ["myApp.Core", "myApp.Foobar"] 
        },
        { name: "../myApp/modules/Login.js", resourceName: "myApp.modules.Login",
          dependencies: ["myApp.modules.Login", "myApp.modules.LoginUi"...],
          layerDependencies: ["../myApp/Core.js"]
        },
        { name: "../myApp/modules/Secret.js", resourceName: "myApp.modules.Secret",
          dependencies: ["myApp.modules.Secret", "myApp.modules.SecretUi"],
          layerDependencies: ["../myApp/Core.js"],
          authentication: 42
        }
    ]
}

Now, instead of serving the built JS files directly as static files, I let the requests go through a controller in my server-side application, which checks if the JS layer requires authentication and whether or not the user is logged in with the necessary access.

This does have certain cons. The JS files aren't cached, and if I had all my JS in one build layer, the application would probably load slightly faster. There's of course also a limit to how nuanced it's worthwhile to make the layers. More layers mean more hassle, but also more finely grained module access.

I'd be interested to hear others chime in on this as well. It's a good question.

Upvotes: 1

hugomg
hugomg

Reputation: 69934

When a user successfully logins the server should provide him with a session token. The Afterwards, whenever the user requests a resource (either via just redirecting the browser or via AJAX) he shows the server his session token (either by storing it in a cookie and sending it automatically on all requests or by explicitely passing it in the body of an AJAX request)

The server can then use session tokens from the users to control authorizations server-side, rejecting any request with an invalid or outdated token.

https://en.wikipedia.org/wiki/HTTP_cookie#Session_management

Upvotes: 1

Related Questions