Tag Info

New answers tagged

1

Background There are three places where final can show up in Java: Classes (JLS 8.1.1.2) Methods (JLS 8.4.3.3) Fields (JLS 8.3.1.2) Making a class final prevents all subclassing of the class. Making a method final prevents subclasses of the method from overriding it. Making a field final prevents it from being changed later. Misconceptions There are ...


1

Another advantage to String being final is that it ensures predictable results, just like immutability. String, though a class, is meant to be treated in a few scenarios, like a value type (the compiler even supports it via String blah = "test"). Therefore, if you make a string with a certain value, you expect it to have certain behavior that is inherit to ...


2

Well, I think your design is fine I would only recommend you only a simple thing on how to store the roles. I have here a system that has almost the same concepts. It is not based on roles as per the name. So I have a user session object with objects of type Map that store the permissions that the user has. And this Map objects is filled on demmand It will ...


1

I used to work on a system with fixed number of tables/directories (different from yours), so I didn't use role-base security schema like the one of yours (or of file system, or of SQL DB). I used linear access level. At high level, the thing is similar though, especially with your question. Nevertheless, wherever and however you store Access Right on the ...


0

I think it would be best to store a List<Action> in the session. Resolve this list based on the roles the user has at the beginning of the session. Unless permissions change often, it is enough that the user permissions are updated on each login. On a sidenote, I would not design it so that Role has a List<Module> but instead a ...


1

A method that I have used is to allow Admins to effectively assign discontinued users to a role marking those users as such. The role can be called whatever you like, such as "Disabled", while active users would be assigned to a role of "Active". Then I just prevent access via the Authorize annotation at the Controller(s) level: [Authorize(Roles = ...


0

There should be very little overhead associated with getting the user permissions on page load, so do that. Don't use the session to store much of anything. This will allow permissions to be dynamically changed by admins (so that the user won't have to login again). Rather than develop a detailed role infrastructure, why not consider something simpler ...


2

If you only need to cater for such a small amount of users, you could also consider delegating credential storing to some other service, such as Google or Facebook. This is usually preferred since the user needs to remember one less set of credentials and you have one less thing to worry about. That being said, this could be problematic if you want to run ...


0

You can take the file approach as long as you acknowledge and understand all the implications of this. There are many applications that do this. For example adding/editing a user will possible require a re-configure/re-start of your application and the involvement of an admin. Depending on how your application will be used that could be too slow or perfectly ...


0

he could gain pretty much all of that from looking at the unobfuscated source of our app. This is DEFINITELY a concern. If that's the case, then your application definitely has a major security flaw. That could be anywhere from hardcoding password/keys in the code, to writing your own crypto algorithms, to just leaking out information just because of ...



Top 50 recent answers are included