Exploring what does “Remember me” checkbox mean on the Login page powered by ASP.NET Forms Authentication

The colleague of mine recently asked me to check if our Login works correctly. His concern was application’s prompt to login although earlier this day he logged in with “Remember me” checkbox checked. It was a surprise for me because our configuration had this statement:

Since I am not an original developer of the application I am currently working on, I was pretty sure this statement means “Keep user logged in for 12 hours”. I figured out I was wrong and in this post, I will explore what does this “Remember me” checkbox actually mean.

Session timeout and Forms Authentication timeout are not related at all. ASP.NET is designed so that information about currently logged user is not stored in the sessions as I presumed. In contrast, when the user logs in it creates a so-called forms authentication ticket. This ticket is a long string of different characters with encoded user information in it. This ticket is then returned to the browser with a request to set a cookie with given ticket. To illustrate:

Next time when the browser does request to the server, it sends the same cookie with the ticket inside back to the server, for example:

By processing the accepted ticket, the server knows which user has sent a request to it.
As you have probably noticed, no session is involved in this browser-server communication. This is how ASP.NET is designed. See details here.

Hence, my configuration <sessionState timeout="720"></sessionState> has nothing to do with Login functionality of my application. It turned out that ticket expiration can be also configured by adding the following statement to the configuration file: <forms timeout="720" />. Finally, my “timeout” configuration looks like this and my user is not logged out for 12 hours:

“Remember me” checkbox only helps user’s authentification to survive the browser restart. So, now my user is not logged out every 30 min (this is default forms timeout) but why do we need this “Remember me” checkbox? When this checkbox is checked the server not only asks the browser to store its ticket, it also asks it to persist this ticket for a certain amount of time. For instance, look at this response when the checkbox is checked:

When the browser receives such a response from the server, it saves the cookie with the ticket in the file system, which makes possible for the cookie to survive browser’s restart and even operating system restart. Read more about persistent cookies here.


The programmable web

I have spent many years in the University teaching students software engineering and writing my Ph.D. theses. During that time, of course, I had to read a lot of books and papers. One interesting point kind of carved in my mind: many years all kinds of software researchers and practitioners were trying to invent components. It was and still is the way too overloaded term. Different software concept was considered as components, from classes and functions to DLLs, JAR files and other things special for the operating system or some kind of framework. Like for example Angular 2 has components concept today as well as a WEB as a whole has now a concept of WEB component.

The primary characteristic of any component has always been some kind of secret and different kinds of components failed in different ways to hide their secrets and provide reusable abstractions. However these days we have another kind of component – a web service running somewhere. I am just amazed how abstract it is. The only thing you have to know is the URL, the address of the resource you want to utilize in your application and that’s basically it. Dave Thomas once in the interview mentioned that someone should have created Intel of software components instead of tons of frameworks. Well, today’s frameworks are not that bad anymore. But we almost have the Intel of software components. The only difference is that this Intel is not a single company but a service through which you can select whatever component you want to use in the application.

I am talking about http://www.programmableweb.com/. It looks like a marketplace for software components. Recently I had to build an application which would ask users to record some video from whatever device, take and store these videos on the server, transcribe videos and store information about videos as well as transcriptions in some kind of storage. Sounds like a really big project? I was able to do it in approximately 2 weeks including investigation and proof of concepts.

First search for some kind of video recording, playback, and hosting service:

After a little bit of investigation CameraTag and Ziggeo proved to be components which could be embedded in my web applications to record/playback videos and also could host these videos and provide fast access to them.

Great, now that I have my videos and access to them, I want to transcribe them. For this I just select IBM Watson service (which by the way is the great one):


Next, glue these web services together and application is ready. And of high quality by the way.

To conclude, I would like to say that now is a really great time for developing software applications. Even a small team can build something complex and large by grabbing whatever complex component it wants and access it almost instantly. One also can build his/her own business in building such software components. The business model is pretty simple, people will pay you for computing and storage resources you provide to them. IBM in my example earns money for their artificial intelligence algorithms and Ziggeo/CameraTag have their money for capturing, storing and playing video resources.


What happens when you do sync in your GitHub Desktop?

I am by no means a git expert, but here is what I have learned when I was trying to answer to myself the following questions:

  • How to think about and visualize git branches to improve understanding of what is going on?
  • What actually happens when I press sync button in GitHub Desktop?
  • Why when someone does it to save their commits on the server, git automatically creates another commit called “Merge branch master of…”?
  • What does diff tool show when one looks at changes made in this automatic commit?

Let’s start with the first question. People use different ways to illustrate what happens inside git system. Some of them make me gaze at the picture for minutes trying to make sense of it. But one way actually helped me to understand better the answers to my questions. It is pretty simple but reflects how things are actually done. The branch structure is shown as a tree data structure with two types of nodes: commit and branch identifier. These nodes point to each other. Here is how the main branch may look like in such a visualization:

It is helpful to think of this situation as master branch has changes made in commit A and B. If the branch pointer does not point to some commit, either directly or indirectly, the changes of that commit are not incorporated in the branch.

So, what actually happens when I press sync button in GitHub Desktop? Since Git is distributed version control system each developer as well as remote server has its own copy of the whole repository. And sync tries to make your local copy of repository the same as remote server’s repo. For this it does 1) pull command to harvest changes form the server, which is not present in your local repo and 2) push command to push your changes, which are absent on remote server.

Why when someone does sync to save their commits on the server, git automatically creates another commit called “Merge branch master of…”? This is an interesting question and the one, which motivated me to write this post. Let’s see what happens using an example. Imagine, you have a remote server with your repository, most probably GitHub. And you also have a clone of this repository locally. You have one branch master and two commits A and B in it. This is what is shown in the previous illustrations. But more accurate way to think of this is the following one:

That is, in reality, you have two master branches on your local machine and one on GitHub. Looks like a mess? Yes, it is a mess! This is why you might have difficulties with understanding Git just like I have. But anyway, imagine now someone in your team did the commit C into your GitHub repo:

Now your GitHub branch is ahead of your local one. Meanwhile, you have done some changes and created your own commit D:

Now all your branches point to different commits! The origin/master branch can never be changed by yourself and therefore it stays pointing to the command B. At this point you press sync and first what happens is pull command. This command consists of two other commands: fetch and merge. The fetch command updates your origin/master local branch:

At this point, your local master branches have clear divergence in their path. But what you probably want when you press sync button is to have them synchronized. This is done by the second component of pull command – merge. Its task is to take the origin/master changes, in our case the commit C and incorporate it in master, in other words, it unites two histories in one:

Merge commit is special, it can have more than one parent. At this point, we can answer the last question: What does diff tool show when one looks at changes made in this automatic commit?. So on the left side we have master branch before the merge and on the right side – master branch after the merge. Now, origin/master is a bit too old. The push command will bring everything to balance by updating remote branch with local one:

Let’s have a look at git log origin/master:

We can see the C commit in the result of the merge. Since branches histories are merged, both C and D are the parts of origin/master and master branches, in the picture they are kind of in parallel to each other, but in git log they are ordered by the creation time. The C commit, however, is only virtually part of the history of these branches. Physically C commit is still kind of branched off and only M commit which is basically a duplication of C made possible to have C in the history of master and origin/master branches. You might ask why don’t just put C in place of M? I think it’s not done like this because C might contain conflicting changes with D and if we simply put C in place of M this would possibly delete or destroy changes in D. We could of course go for the merge process resulting C in place of M, but if merge process would require considerable changes, the result would have been not pure C it would have been some kind of mutation. Furthermore, moving C in place of M could destroy other branches which could potentially branch off from C and did not expect to have D commit changes in them.

Confusion adds GitHub Desktop wich tries to be smart and hides from the user C commit which is a redundant one (note, C commit is skipped):

Hope this helps you understanding your sync button. To avoid complications of merging things, always do sync just before making your commit and don’t forget to do sync after you have done your commit.

If you like this post, please follow me on twitter, see you there!