Ranting about a rant

First I stumble upon a rant. I often read these, write a long comment about all their faults or misunderstandings leading to their outburst of hatred, but this time it turned out that the site hosting the article has a botched comment form. It tries to load WYSIWYG editor which in turn hides the original <textarea>. Sigh.

Anyhow, the original rant is about Java and Spring Security. It boils down to author drawing lines between Spring Security features (storing credentials) and PHP (in-)security in general. Author is also pissed off because class names are long, and fully qualified names are even longer.

Too bad.

Storing credentials in Sessions are required if you want to reauthenticate without prompting user for a password (again). Why would you want to reauthenticate, isn’t authentication enough? Well, what if the user loses his/her rights while he/she is logged in — wouldn’t he/she need to be kicked out, or have some access taken away?

You can now say that well we can just receive an event whenever user’s rights change, afterall they are in our own SQL database. We might even fire the event from a database trigger. There are real use cases for not having your own user, password or authorization database and that other system might not support events from changes.

Reauthentication has other purposes as well. You might just check if the user’s password is still valid. You might want to do this on each request, or each more dangerious action for example.

Next up, long class names. Crying for the sake of crying. Why save up on naming if disk/memory is practically free? Obfuscation is not a good use case for open source (integration) project. You want understandable names. Let’s break down org.springframework.security.­web.authentication.preauth.websphere.­WebSpherePreAuthenticatedWebAuthenticationDetailsSource:

  • org.springframework.security — the project identifier
  • web — module identifier
  • authentication — clue about relation to authentication
  • preauth — this is not form login, it’s about accepting already made authentication based on some verification token (X.509 certificate for example)
  • websphere — this code must be specific to Websphere (application server)
  • WebSpherePreAuthenticatedWebAuthenticationDetailsSource:
    • WebSphere — we went through this clue already
    • PreAuthenticated — this as well
    • WebAuthentcationDetailsSource — this class must be a source of WebAuthenticationDetails

Disclaimer: I didn’t do any fact checking above. I might have mistaken a bit (doubt it), but a lot of this is “decipherable” just be reading it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: