PDA

View Full Version : ExtJS authorization best practice



jpartogi
23 Aug 2009, 9:22 PM
Hi all,

I'm quite new with ExtJS and RIA in general and I want to ask what would be the best practice for doing authorization in ExtJS.

Case:
I have a user with USER ROLE and this user can not access several buttons/widgets in the application. Now what would be the best practice to prevent un-authorized user to access these buttons/widgets?
1. Do I use the server side language (and embed it in the html) to hide those button for un-authorized user
2. or do I just display the button and send back an error message to the view if the user is un-authorized to access the action for this button.

What would be the best practice in doing this in Ext-JS? Any insights would be highly appreciated.

Kind Regards,

evant
23 Aug 2009, 10:10 PM
I think it makes sense to either hide or disable the buttons if they user can't complete the action, no point having them wait for a roundtrip to the server to find it out. A common thing is to have the server send back the JSON after doing authorization checks.

Regardless, you should always still check if the user can complete the action on the server.

jpartogi
23 Aug 2009, 11:10 PM
I think it makes sense to either hide or disable the buttons if they user can't complete the action, no point having them wait for a roundtrip to the server to find it out. A common thing is to have the server send back the JSON after doing authorization checks.

Regardless, you should always still check if the user can complete the action on the server.

1. Would it be better to return a JSON object that return authorization data and disable/enable the button based on that
2. Or use a server side language (i.e PHP) and hide the button with it

I kinda don't like the second option because my template would look really gross because having to mix server side language and Javascript. So I'd prefer to keep the template clean from server side language, but I don't know whether the first option is good or not.

Kind regards,

mitchellsimoens
24 Aug 2009, 5:54 AM
If it is important... do both. Using Firebug, anyone can do anything with javascript so nothing is actually secure.

Never trust the user.

brianghig
7 Sep 2009, 4:51 PM
Using Firebug, anyone can do anything with javascript so nothing is actually secure.Very true. While there are some good front-end practices, remember that a request can be made from things outside of your front-end control, so secure your server-side code as much as possible with validation, authentication, and authorization.

To address hiding widgets and not embedding your server-side code in HTML / JS, you may want to consider wrapping these elements in a JS class that will determine, based on role, whether or not to even add the element to the DOM (as opposed to adding it and hiding it).

Mike Robinson
8 Sep 2009, 6:27 AM
A few suggestions, primarily for Intranet deployments:


Use LDAP/Open Directory. This is a universally-understood framework that your network is probably already using. Your corporate IT folks are undoubtedly already using it. Avoid requiring them to set up and maintain "something different."
Secure the entire site at the server level, again using LDAP, so that people who have no authorization to use the site cannot even get there.
Use LDAP roles to determine what the user can do. Store this information at the server side (e.g. in Session data) and provide an AJAX call or result-record to inform the client. The client can use this information to appropriately set the visual controls, but this alone is not enough. The server must also, independently, validate every request that it receives. There must also be an appropriate means to validate the content of cookies, etc.
If authorization is an issue for an application, that app should be using https:// transport unless the network is known to be completely closed and the information being exchanged is not confidential.
You must actually and methodically test the application using less-than-all-powerful user identities. Many developers neglect to actually do this.