Best practices - login screens

[daemach]

I want to create a login screen that is essentially a viewport - a white screen with a form panel anchored in the center. My secured area's layout is a viewport too. What is the best-practices way to handle a login scenario where the user logs in successfully and the login viewport fades away to reveal the secured area's layout? We'll want to reuse the login window for session timeouts, etc.

Should this be a standalone module or integrated into the admin module, since it's a root function?

What would be the best way to structure the module so this can be reused, and cannot be bypassed?

[brian.moeskau]

You might want to move this to non-Premium, as I'm sure many users can contribute to the discussion. Since we aren't building production end user systems (or I guess I'll just speak for myself) I don't have any good code examples or patterns to give you, while I'm sure others have code already written for this.

[daemach]

It would be cool if one could do that from the thread tools menu or by editing the root post.

[brian.moeskau]

I guess only moderators can move threads. Moved to open discussion.

[saJoshua]

Hi Daemach,

I have used the approach of separating the login window and the rest of the application because it's just too easy to hide the window and continue if it's only a panel / layer above the rest of the app.

I'm still getting up to speed with ExtJs, but I know that configs can be loaded in remotely. I guess this could mitigate the above weakness if used correctly. You could validate the login via ajax, then load the config for your application remotely. If the user's session times out, maybe you could destroy the application components to prevent bypassing the login screen.

Joshua

[murrah]

I am building an app that uses the following approach that may (or may not) work for you. It is still being built and when I have finished I will post it (or a link) here: http://extjs.com/forum/showthread.php?t=21517 It would be great if you could add your approach to that post also.

I am using ColdFusion on the server side and users are authenticated via the session-based authentication method. ie CF users are identified via a cookie and user authentication status is stored in internal session variables - when the session times out (eg 20 mins inactivity) the authentication data is destroyed and they are "logged out". CF still remembers who they are after log out because of the cookie.

In my app, a new or returning user is auto "authenticated" as a Guest - no username or password is required. As a Guest they get limited functionality. Users that have signed up can then log in and based on their "role" (Guest, Member, Editor, Admin) they get more functionality in line with the permissions that come with that role.

Functionality is controlled by asking the server for the permissions for that user and enabling/disabling chunks of the app as required. The initially rendered Ext components assume Guest level and then after rendering, the server is asked for the permissions for the user (in case they have simply refreshed / reloaded the page at some stage after logging in). After login, the server is asked for the permissions. The callback on the permissions request enables/disables functionality as required. At session time out (checked on each server request and also by a client side timeout checker-->ajax request if the time since last server request is close to the server timeout) the user reverts to Guest and the appropriate permissions for Guest cause the app to hide functionality and relevant data again.

Obviously the user can hide/show functionality by manipulating the app via the Firebug console (for example). Therefore EVERY server request checks whether the user has the permissions to see the data they are asking for. If not, they get a "You dont have permission to see that" message. And, when a server session times out, any components that have data that Guests shouldn't see are destroyed via the callback on the Ajax request and a login dialog is displayed so the user can log in again.

As I say, this approach is still being built and tested and may not work exactly as I have outlined.

Cheers,
Murray

[DigitalSkyline]

In my situation I have a login that is separate from the application. Once logged in the user is directed to another page (unfortunately this means reloading Ext, I may choose to refactor this some day).

For my applications, most of the functionality is downloaded separately. So I'll have the main application load a script from the server, the server determines the correct user level, and serves the script based on this. For example I'll download a different toolbar/menu for a User vs Admin, but the core component will be the same. The js is delivered in one request although they are actually separate files, they are joined on the server. This could be further enhanced to eliminate any chance of hacking the client by delivering completely different scripts, but maintaining separate components for each user level would be a nightmare.

However once a script is downloaded as I'm doing it, its very difficult to hack because the scripts are eval'd... you can only see the source by examining the response (and this can be obfuscated on the server).

I think this is probably a more secure way of handling things rather then downloading entire apps, and having the client request what permissions to allow on the client.

And just as Murray, every data request is authenticated, so the server remains the security authority.

Also, my approach for handling session timeouts and errors include using this:
http://extjs.com/forum/showthread.php?t=21681

So a request might error out, it can be handled by notifying the user, and in my case, directing the user to the login page.

[daemach]

Thanks to everyone in this thread. Great information.

[josh803316]

*Not sure if this is the place for my thoughts/questions on this, but I'm trying to develop something similar so I figured I would add my 2-cents.

I am building a similar ext (portal/complex layout) app that will require users to login as well, and then be session tracked (using cookies and session_id) The Server-Side of the site will use perl/apache/mysql...in responses to the ajax client side requests.

I would like for,
1)The login form to be displayed instead of a menu system, but still show a working demo of most of the sites features/example portal content for non-logged in members. Hence the need for the login/account creation area to be in the same area as the portal...

2)As soon as the user logs in, the portal navigation area changes, the login form is removed and the menu systems/advanced features/unique user content are rendered. This is all displayed with a nice loading animation as login is processed and new portal/layout is displayed (after ajax data returns)

3)The portal/layout changes so that the rendered content/features are based on the unique user/sess_id

The session based interaction from that point on will create the unique user experience for the logged in user. I notice, however, that across the web most login/password form submits require complete page reloads and redirects. In line with this thread I'm looking for the reason for that, and if it is better for my site to do a complete redirect to a new portal site for logged in users....or if it is merely a preference thing.

My thoughts were to:
1)On the server-side, have a field in the db which would indicate logged in status (defaults to false)
2)Only way to set that value to true would be through the proper form submission (correct user/pass)
3)All subsequent ajax requests reset/keep the logged in value as true....if user_id/session_id pass the server-side test
4)If that value isn't true, always render the login form and default demo page....
5)Have an idle timeout function on both server and client, that works with sess id/user_id so a users session couldn't be hijacked later
6)If user returns later, inside timeout, but has correct cookie, session remains active (depending on cookie timeout of course)
7)In my case, the user specific site information wouldn't be rendered by firebug, etc....unless the user_id/session_id/logged_in_value/cookie...were all in agreement.

[kesteb]

The session based interaction from that point on will create the unique user experience for the logged in user. I notice, however, that across the web most login/password form submits require complete page reloads and redirects. In line with this thread I'm looking for the reason for that, and if it is better for my site to do a complete redirect to a new portal site for logged in users....or if it is merely a preference thing.


I can think of serveral reasons for doing it this way. For one, javascript can be manipulated within the browser context. Once the code is loaded, it is outside of your control. So, if you load your application, with the expectation that you can control access to specifiec parts thru client based access control, you may be in for a rude awaking. I doubt you can do it with server side assitances.

I am using a seperate login process to establish context. The server side maintains that context. Once context is established, a server side redirect is made to the actual application. This, of course, forces a reload of Ext and any application specifc modules. I figure this is a good thing. It creates an initial, known, default context on the browser side. Any attempts to hack, break and/or manipulate the initial login code is now reset to known defaults.

I have also made the attempt to only load modules that are neccesary for a given level of access. i.e. I don't load modules of admin functioniality for non-admin users. This is controlled on the server side.

The problem I am having is with client side context management. Most server backends usually send a 302 redirect when context is lost. The browser quite helpfully intercepts those 300 level codes and operates on your behalf. This of course, royally screws up any code that is expecting a specific response, such as a json data stream of records and instead recieves the login page instead.

A work around is to send a data structure back to the client when context is lost. The data structure would nicely inform the client that context is lost, please redirect to the login page. For the most part this works. I send a data structure that looks like the following:



{
success: false,
action: {action: 'redirect', url: '/login'}
}


Expecially if you can get access to the response headers when doing an ajax call. Unfortuantly, this dosen't work when using the various store methods. As far as I can tell, they don't give access to the response headers when a failure happens. But then I am still working on this.

[DigitalSkyline]

The best solution I've found for this is HendricD 's user extension ( http://extjs.com/forum/showthread.php?t=21681 ) as posted above, which allows you to handle response codes.

[hsurya]

I want to create a login screen that is essentially a viewport - a white screen with a form panel anchored in the center. My secured area's layout is a viewport too. What is the best-practices way to handle a login scenario where the user logs in successfully and the login viewport fades away to reveal the secured area's layout? We'll want to reuse the login window for session timeouts, etc.

Should this be a standalone module or integrated into the admin module, since it's a root function?

What would be the best way to structure the module so this can be reused, and cannot be bypassed?

I built a similar kind of login scenario, I don't know whether this kind of login scheme you want.
Actually I use messagebox, I take only the screen, remove the message and replace it with a login page uploaded externally (using .load).
Username and password validation is done in the external page, then the message (wrong login or successful login) will be written in a <div> on the messagebox flyout.
When a user successfully login, I use cookies instead of session to change the feature that is allowed only for that particular user, then change it one by one using javascript on the external success-login page (for this purpose, I enable the parameter script:true in the .load class).
That's it, a very messy programming, but at least it is working, until I have time to make it better. You can see it in my website: www.juhono.com

[irina]

Hi,
Could you please give a more detailed link on your code. It is hard to find something on your site.
Thanks a lot,
Irina