0x33c0 / securityrat Goto Github PK

This is a collection of things that should become cleaned up or adjusted. Points get dumped without further considerations.

User authentication and management: The whole user management is separated into many different classes at different packages. Also, there are two different interfaces to access or modify the same user data (either via the AccountResource or via the UserResource). Also, CAS and FORM authentication are not really separated from each other, which makes understanding the overall logic very hard.

Scalability: Depending on the requirements, the software may not be as scalable as needed. Thousands of concurrent users could be a problem because database access is always blocking. (But maybe this is out of scope...)

API: The application can be operated by using its RESTful interface. This is nice, but establishing an authenticated session is relatively hard to achieve (mainly because of the X-CSRF-Token).

Web Client: The web client is built on outdated or discontinued frameworks (e.g. AngularJS 1.x, bower, grunt, etc.). Unfortunately, upgrading to Angular 2+ and webpack does not look very simple because early JavaScript did not use any kind of import or require mechanism for its dependency management and relied on the global window scope.

To be continued...

Since the activation_key identifies a single user uniquely, the column should be unique as well in the database. Otherwise, very unlikely but possible collisions of the random algorithm could cause exceptions.

The same applies for the reset_key column.

At the moment, the password confirmation is only required by the client web application and thus can be circumvented easily. The REST endpoint does not affect the server's/session's state in any way and can be omitted without further restrictions.