Archive

Monthly Archives: April 2016

Passwords are troublesome. I can tell they’re troublesome because most website have the “Lost your password?” button readily available. Because password tends to be lost, or forgotten, or entered via keyboard with different layout (Try using the “£” symbol and good luck to all american-keyboards users).

Passwords are crackable, as majority of people don’t understand the likelihood of someone trying to break down their password. So to make the life of hackers slightly more difficult we now have the CAPTCHA mechanism, that aside from being already cracked by hackers is simply annoying. In fact, the “Lost your password?” is annoying too – you might as well call it “Annoyed? Click here”. Think of it this way – the user clicking this button is only one step away from not using the service.

And funny enough – this button is actually the solution to our problem. When you click button a two-steps authentication is initiated – usually via email which includes an unbreakable code that allows to update your password. Well, why just change password? Why shouldn’t it allow access to all the service?

With this reasoning, once you can you edit the password – the service is practically accessible and should therefore be so!

So instead of asking the user for his username (which is usually an email anyhow) and password – why not simply asking for the email?

So here’s the entire procedure

  • user open service, type in his email, click submit
  • A special token with time of creation and the user’s IP is created and sent to the user’s email
  • User click the link in his email
  • Token is sent back to the server and is verified that the IP matches and token hasn’t yet expired (let’s say one hour from token creation time)
  • A new token is created with user-id and user’s IP and sent to the user, encrypted
  • The user cannot decrypt this token but whenever he communicate with the server he passes this token along to authenticate himself

The browser should keep the authentication token for a reasonable time – let’s say 3-6 months, during which the user won’t have to go through this process again. This cookie should not and cannot be simply copied to another machine as it require the computer to have the same IP. And if you’re truly concerned with security, the service can ask the user for his public PGP key along with his mail and thus send him an encrypted mail only he can decrypt.

The only problem with the mechanism that I found is that it requires your user to temporarily leave the service and check his email. How many users will you loose because they forgot to return and how many will you loose because the password was just another hassle they didn’t care to handle?

Advertisements

Some might say javascript encourages nesting, for example;

var greetDeeplyCurried = function(greeting) {
  return function(separator) {
    return function(emphasis) {
      return function(name) {
        console.log(greeting + separator + name + emphasis);
      };
    };
  };
};

Personally, I don’t like anonymous functions. They make it harder to debug. If you do use an anonymous function, please still give it a name. note the for

var bar = function () {…}

, the function is still anonymous. You should either write

var foo = function foo () {}

or

function foo (){}; var bar = foo;
  1. I don’t like creating function inside other functions, since I don’t know how many time the wrapping function will be called. Simply define two function and let the wrapping called the internal.

Nesting function is the lazy-solution to handle Javascript’s scope issue, as function don’t really hold a scope on their own one might find it easier to have all the scope nestled together so for sure you’d know, which scope is being used.

I would resolve that using bind, call and apply to determine the specific scope I would like my function to run. Generally I would avoid outside-the-function scope variables – each function should use only what is passed into it, and with the use of bind you can send parameters from different sources: in this example

myButton.onclick = foo.bind({},myVariable)

myButtons will have two parameters – myVariable and the onClickEvent, both coming from different sources.

That’s being said, My server-side has a lot of sequential asynchronous operations – load a topic and use its data to load the community and the member and then makes changes, write them and send the result to the client side.

I suggest a Sargent to manage our tasks on our behalf.

sergeant({ topic: { table: db.topic,
                         data: userNewTopic,
                         after: sergeant.validate }, 
           member: { table: membership,
                     load:{ userId: authUser.id }, 
                     before:getTopicCommunityId,
                     after: sergeant.isSuccess } ,
           savedTopic: { table: db.topic, 
                         before:prepareForSaving,
                         after: sergeant.isSuccess },
           finalize: { json:true }},
           “topic,member,savedTopic, finalize”,  callback);

or

sergeant({ map of tasks },
           [ordered list of task name], methodToRunWhenDone);

A task has the following properties

  • table – a node-ORM object
  • load – either a object-id value or a node-ROM compliant map of properties
  • multiple – if the object exists, load will assume multiple results. Multiple can be a node-ROM compliant list of properties such as order, limit, order, and groupBy
  • data – data placeholder to be passed on or used by save
  • save – boolean flag. When save=true, data will be saved. The repository[taskName] will then store the save operation output.
  • before – function to be called before commencing the task’s main operation.
  • after -function to be called once the task’s main operation is completed
  • json – will run toJSON() function on items in the repository

before/after functions may return the following values

  • true/ undefined – continue operation as normal
  • false – the main operation will be skipped or discarded. If before return false, after will not  run as well
  • Error – sergeant will stop its operation and call methodToRunWhenDown(error)

load overrides data (so data acts as default value until load is pre-populated)

A Task with load but save=true will throw an error  before any task starts.

[ordered list of task name] can either be an array of tasks-names or a comma-separated string.

The before and after functions’ parameters are (repository, taskMap, currentTaskName)

json runs after the main operation but before post. Its value can be one of the following

  • true – will json-convert the entire repository
  • [] – (empty array) will json-convert only the current task result. if there’s no data or load properties for the task it will exit before running
  • [taskNames] (array of strings or comma-separated string) – will json-convert the specific tasks output. json is agnostic whether the task have run or not
  • undefined/false – won’t try to json-convert

 

If repository[taskName] is an array, json returns an array of objects, each was json-converted.

A good practice will be to run post the last json and delete any unnecessary temporary repository elements.

so in conclusion, Sergeant.js is used to run a list of db-related tasks (which seems to apply to most of my server-side methods) in a sequential order, thus saving the need to nest your operations in an unreadable fashion.