PDA

View Full Version : authorization and access based on groups



lormitto
5 Feb 2010, 5:01 AM
Hi,

Could you point me to where I can find "best practices", tutorial, example of how to resolve authorization in extjs.
Another thing I would like to learn is how to restric users access to particular parts of interface built in extjs.

Thank you for any help.

dlbjr
5 Feb 2010, 5:56 AM
//Create a Global Object such as this
var User = {
Username: '',
Password: '',
Name: '',
UserLevel: 0
};

//fetch data on log in and set values of the Object
User.Username = 'A987678';
User.Password = 'abc123';
User.Name = 'Howdy Duddy';
User.UserLevel = 3;

//Then you can reference this object throughout your code
if (User.UserLevel >= 2) {
//Allow in part of system
}
else {
Ext.Msg.show({
title: 'Security Alert',
msg: 'You do not have access to this part of the application.',
buttons: Ext.Msg.OK,
closable: false,
icon: Ext.MessageBox.WARNING
});
}

cweise
17 Feb 2010, 6:45 PM
Thanks for your message but couldn't somebody change these values by using firebug and have higher user level?

realjax
18 Feb 2010, 12:06 AM
Yes, you can *not-NEVER-NIE* have your security implemented client side based only.

realjax
18 Feb 2010, 12:13 AM
My client side implemention of 'security' is like so:

I first load a part of the application, showing the login dialog.
When the user is succesfully logged in I load the main app. ( using YUIloader by the way).
This way, the changing of users is never done in the main app itself (it always loads with a logged in user). Saves me a *lot* of headache.

Each request for data is of course verified on the serverside. ( is this user allowed to see this data ?)

I don't care if a user hacks the clientside so he can see more of the interface than he's supposed to.
As long as users can't see or change data they are not supposed to I don't care what they do.

dlbjr
18 Feb 2010, 5:48 AM
In that case, you can change what ever parameter you are using to tell the server who you are to some other value. It can be the username, level, or any other value.

My intent was to show you how we use a User object to maintain the data on the client.

We actually create an encrypted key from the username - password - level and keep it on the client side during authentication. The date stamp and user name are used to generate the key on the server. The key is stored in a table on the server during authentication. This key will be different every time they log on. This key becomes another item of the User object in Extjs. This key is passed back to the server on any data calls. This key is used to let the server side know who is making the call


If they can parse the key to become another user, then let them in!

Later,

David Bryant

realjax
18 Feb 2010, 6:30 AM
In that case, you can change what ever parameter you are using to tell the server who you are to some other value. It can be the username, level, or any other value.

You can, but it won't change your session on the server, so no harm done.




We actually create an encrypted key from the username - password - level and keep it on the client side during authentication. The date stamp and user name are used to generate the key on the server. The key is stored in a table on the server during authentication. This key will be different every time they log on. This key becomes another item of the User object in Extjs. This key is passed back to the server on any data calls. This key is used to let the server side know who is making the call
If they can parse the key to become another user, then let them in!

Later,

David Bryant

Interesting. Why so complicated and not simply create a session on the server side?

dlbjr
18 Feb 2010, 6:48 AM
Stop thinking of one application.

We have one authentication method and many sub web application as in a manufacturing facility. We do not maintain Session State on the server. It is not needed. A person can stay logged into a web app for hours. The session on the server will have ended. We have many web servers using a centralized authentication web service. The key can be seen from any database system from the "Server" side.

Hope this helps,

Dave

realjax
18 Feb 2010, 6:54 AM
We have one authentication method and many sub web application as in a manufacturing facility.

So do we. :-)



A person can stay logged into a web app for hours. The session on the server will have ended.

That's of course easily prevented.



Hope this helps,

Dave

Yep thanks for the info!
It hasn't convinced me though. ;)

Mike Robinson
18 Feb 2010, 7:02 AM
It's worth considering that ExtJS is usually deployed on intra-nets, and (let's face it) most of those are going to be: Windows-XP and IIS. And if that be so, it's okay to take advantage of what has been built-in to that environment. Both the server-side and the client-side are known quantities; both of them know how to maintain a notion that "you are logged-on as" and to do that at a server level, irrespective of mechanisms such as "Sessions."

If you watch a typical interaction through, say, Firefox, you can actually see it at work. The client submits a request; the host answers "Not Authorized"; the client proffers a magic cookie; the request is accepted (as are others, for a while). The AJAX program sees none of this; nor does the user. (N.B: FireFox may require the AutoAuth extension in order to work correctly.)

Typically, this login information (and arbitrary properties and groupings related thereto) are maintained in one central place and by one consistent mechanism: Active Directory (nee LDAP); and Microsoft Management Console (MMC) plug-ins. Linux (e.g.) server technologies can talk to that, and tap into that, effortlessly. So does PHP, Apache, Perl, Ruby ... all the usual suspects.

If you are, indeed, in that kind of environment, you pure-and-simple do not need to "roll your own," as you would be obliged to do in "the wild-and-wooly Internet with a third-party hosting company providing the silicon." If the user connected to your site ... if you now have in your hands an AJAX-request packet, then you already have a trustworthy source of identity. You also have, through simple LDAP queries, everything you need to know about what is or isn't authorized.

It really is the best thing to do, to simply make the LDAP queries with every "controlled substance" AJAX request you must deal with. You don't need to cache that information in a session. Just write some common-subroutines that know how to ask the questions.

To the extent that you need for the client to know what is and isn't possible (i.e. what the host will and won't allow), you can either provide an AJAX-call to tell them, or you can simply alter the JavaScript code that you download in the first place! Since it all originates from the server anyhow, you can arrange e.g. for a particular <script> tag to be included, that will return a block of JavaScript code that is entirely host-generated. It contains variables and flags that are determined by who (the server already knows...) the user is. Mind you, this is just so that the client will appear to know what it's doing: it can gray-out the appropriate buttons and so forth. This is a "soft" mechanism, because the ultimate decider must be the host, not the client. (And the host, similarly, is obeying what LDAP tells it. In an ideal arrangement, the host, also, is similarly subject to yet-another layer of "go ahead, make my day.") The host will refuse certain requests, and the client is graciously informed not to offer to make them.

Something else we can take full advantage of, in this environment, is that there will be no "733T H4X00RZ" if we can keep the perimeter secure against wandering-spirits. Anyone who's out-of-bounds knows that "we're tracking everything you do here anyway, and we'll just fire your butt..." :( Nothing beats a few months of unemployment. So to speak...

realjax
18 Feb 2010, 7:15 AM
Yep thanks for the info!
It hasn't convinced me though. ;)

dlbjr
18 Feb 2010, 7:20 AM
Well written Mike! We use LDAP also. We have created a black box web service on our local AS400 to authenticate against internal then external LDAP servers. Then the black box sets authorization based on the application ID passed during authentication. This is all done in one call in this manufacturing environment. This allows one administrator to manage access to all applications web based or not.

I'm not here to persuade anyone. Some like pink and others like green!

Dave