Monday, 17 February 2014

Authentication scheme

Hello, friends! I am back in Kotka!

The Friend - authentication library of Clojure seems interesting, but because I'm a bad coder, who probably seems to hate sunshine, green grass and all other good things on this earth, I can't be arsed to learn to use this ready but large library that is somewhat complicated for my simple needs. I will probably earn a The Daily WTF - headline with this text, but a coder who has not done that, isn't a real coder :)

I am also too lazy to teach myself how authentication against Twitter's and Facebook's user databases would work. In the spirit of the Worse is Better, I will hard code Feuer (myself) and a few test accounts to the server and I abstract the user-authenticates? - function somehow nicely and I'll write the user management on either CouchDB or the previously mentioned SOME-services. When the authentication works, I'll write the web-API (REST-API?) (and test it somehow...) and begin writing the proof of concept of the client program.

It is unnecessary to dream of the clients and other stuff until the authentication works. How then should it work? In the beginning, the server is minding its own business, and then it finds a surprising login-request from the Compojure's level. The Compojure receives username and a naked password as parameters of the request. The password can not be hashed in the client, since if I remember correctly for the reasons I can't say I understood, the output of the hash-function is dependent on the environment it was called in. Both Java and PHP have given me different hashes in linux and windows for the same input in the past.

The password is immediately hashed with the sha512, and the userdatabase is queried with the username. If the username is found and the password matches, the user is authenticated and the client is responded with HTTP statuscode 200 and the sessionid, which is used for the authentication here onwards. Authenticationsystem updates the sessionid to the sessiondatabase with the current System/currentTimeMillis - value. Sessionid is also associated with the IP it was sent to, so that cracker guessing these ids can't get access to the session although finding an existing session-id unless they happen to be under the same public IP as the original owner of the session.

The rest of the requests do need the session id as a parameter. If the sessionid is found lacking, non-existant, the timeout has happened (the time from the last System/currentTimeMillis is more than 5 minutes (or 30000 millisecons)) or the requesting ip has changed, the request is dropped with response 403.  With every succesful request the moment of the latest request is updated to the currentTimeMillis.

What else? I don't know. The server's authentication scheme is hereby documented. Please tell me if you see something wrong with this.

Oh, and did I mention? I'm back in Kotka after a weekend in Espoo. This week has a possibility of being an awesome one. After my morning exercise (in other words, about three kilometers with a bike) and a couple of cups of tea, I'm ready to bleed some Clojure into the Emacs. Unfortunately I have the thing known as the school blocking my creativity here. Well, today I have a physics class, so the schoolday is in fact a bit more interesting than usually. And it isn't a long day in school. Unfortunately tomorrow I have to rise early for school, so I am not able to code tonight until 2 am. Hopefully tomorrow is different :)

Let me fill the word quota by expressing how dissatisfied I am with the gray the sky has been filled with for almost a month now. I'm sure I spotted the sun a couple of times in the January and the December, but this month has been a british one: rain, rain and not rain but still awfully gray. Luckily when I have been cycling the rain has kept away. In June a little rain isn't that bad (especially when I'm on a bike), but other times only weather condition worse than rain are the snowstorms.

I'm horrified how bad I'm in holding a train of thought even for as small texts as 750words requires. Then again, my daily thoughts don't take so much written space, unless I'm pondering on something locally revolutionary, such as the IM-project, which has filled almost three 750words texts now. Unfortunately all three of them have exploded into this kind of rubbish by the end.

No comments:

Post a Comment