Archive for April, 2009
ITworks Design Journal: GWT 1.6 and GXT 2.0
Posted by BinaryMuse in Technology on April 23rd, 2009
This post is part of the “ITworks Design Journal” series.
ExtJS has been working on version 2.x of GXT, built upon GWT version 1.6. Recently, ExtJS released the milestone 1 "release" of GXT, and I decided to upgrade and see what all the fuss was about.
Before I could test anything, some changes needed to be made to my environent. GWTShell has been deprecated in leu of the new hotness, HostedMode. The "public" directory, used for storing static content such as images and stylesheets, has been migrated to a directory called "war."
Some changes were made to the API in general. For example, EventType is now a class; that means all your code that look like this:
public class AppEvents
{
public static final int Init = 1;
/** trimmed **/
public static final int BuildContainers = 20;
public static final int BuildUI = 21;
/** trimmed **/
}
and this
public void handleEvent(AppEvent<?> event)
{
switch(event.type)
{
case AppEvents.Init:
this.onInit(event);
break;
case AppEvents.BuildContainers:
this.onBuildContainers(event);
break;
case AppEvents.BuildUI:
this.onBuildUI(event);
break;
}
}
Now need to be changed to this
public class AppEvents
{
public static final EventType Init = new EventType();
/** trimmed **/
public static final EventType BuildContainers = new EventType();
public static final EventType BuildUI = new EventType();
/** trimmed **/
}
and this
public void handleEvent(AppEvent event)
{
if(event.type == AppEvents.Init)
this.onInit(event);
if(event.type == AppEvents.BuildContainers)
this.onBuildContainers(event);
if(event.type == AppEvents.BuildUI)
this.onBuildUI(event);
}
A good change, in my opinion.
I was also surprised to see that the look and feel had changed just a tiny bit. Compare the last version’s dialog (including borders, shadows, buttons, and the title bar) to the new version’s:
The differences are relatively minor (except for the buttons, which I will be working on) but definitely noticeable.
There were are few other things I had to change, such as the removal of StatusButtonBar (now you use getButtonBar() on a Dialog and add() a new Status object to it). Overall, I think the changes were mostly positive, and I’m looking forward to checking out some of the other changes.
GWT 1.6
GXT 2.0 M1 (note this link may change as builds are released)
ITworks Design Journal: Authentication
Posted by BinaryMuse in Technology on April 1st, 2009
This post is part of the “ITworks Design Journal” series.
Where I work, we authenticate against an Active Directory server. In an effort to help the consolidation of usernames and passwords, I decided that users of the ITworks app should also authenticate against the AD, and that the user’s role, or permissions, in the app should be determined by groups they are members of in the directory. A bonus advantages of this system is that I don’t have to design any sort of user management piece!
I developed a very simple class, LdapUser, that logs into the AD with a privileged user and search for a user with a sAMAccountName that is the same as what the user entered in the login dialog:
If found, the class attempts to re-bind to the server with that user’s name and the password they entered. If successful, the user entered valid AD credentials. The class then queries the server for an array of groups the user is in, and checks against a known list of valid groups.
If found, the server returns some JSON indicating the user’s proper name, access level, and session-specific API key.
API Key
In order to insure that request for information is coming from a user that has successfully authenticated, every user that logs in is given an API key that is valid until their session ends. Every time the client requests information from the server, the API key must be passed, and is validated against the one the server generated when the user first logged in.
Login Throttling
One thing I was concerned about was brute-force attacks on the site. Since we authenticate against our AD server, it would be a bad thing™ if someone was able to brute-force their way into an IT staff member’s password. Thus, a login throttling system was born.
The system I designed is very simple–it limits unsuccessful login attempts on a specific user. Each time an invalid username and password combination is entered, that username’s "incorrect login count" is incremented in the database. Depending on how many bad login attempts have been recorded, subsequent attempts will issue an error message that the user must wait before logging in again. (I considered making the server thread sleep() for a while, to make it more frustrating, but I feared that the potential to consume a large number of threads was too high, effectively increasing vulnerability to a DoS attack). The time required gets exponentially longer as the number of attempts increases.
Once a user enters a correct username and password (assuming they are not currently in the "wait" period triggered by multiple incorrect combos), their count is reset to zero.
Again, the system is simple, but provides enough security for basic brute-force attacks–which was the goal.
Conclusion
In the end, I ended up with a simple authentication script that authenticates against Active Directory and prevents basic brute-force password hacking. The system works fairly well–if anyone sees any flaws in my logic, or has any comments, please do not hesitate to comment below!