persistent login –“remember me” feature

  1. FACTS:
  • when a machine is reboot, the session will lost, but the token won’t because the token is stored in the cookies
  • a session is in the memory

If you DO decide to implement persistent login cookies, this is how you do it:

  1. First, follow Charles Miller’s ‘Best Practices’ article Do not get tempted to follow the ‘Improved’ Best Practices linked at the end of his article. Sadly, the ‘improvements’ to the scheme are easily thwarted (all an attacker has to do when stealing the ‘improved’ cookie is remember to delete the old one. This will require the legitimate user to re-login, creating a new series identifier and leaving the stolen one valid).
  2. And DO NOT STORE THE PERSISTENT LOGIN COOKIE (TOKEN) IN YOUR DATABASE, ONLY A HASH OF IT! The login token is Password Equivalent, so if an attacker got his hands on your database, he/she could use the tokens to log in to any account, just as if they were cleartext login-password combinations. Therefore, use strong salted hashing (bcrypt / phpass) when storing persistent login tokens.


  • user login in, after authorization of “remember me”, the client’s cookies is updated with a username, and a token; the token->username is also stored into server’s database
  • for user’s next login, the cookie’s token will be used to match the one in the database; if it does match and is not expired, a new token will be generated and the cookie will be updated accordingly. If it does not, either report it as a theft or ignore it. Thus, automatically re-login is finished.
  • even you reboot the machine, you can still login automatically as long as the token is not expired.

Charles’ Recipe

The cookie should consist of the user’s username, followed by a separator character, followed by some large random number (128 bits seems mind-bogglingly large enough to be acceptable). The server keeps a table of number->username associations, which is looked up to verify the validity of the cookie. If the cookie supplies a random number and username that are mapped to each other in the table, the login is accepted.

At any time, a username may be mapped to several such numbers. Also, while incredibly unlikely, it does not matter if two usernames are mapped to the same random number.

A persistent cookie is good for a single login. When authentication is confirmed, the random number used to log in is invalidated and a brand new cookie assigned. Standard session-management handles the credentials for the life of the session, so the newly assigned cookie will not be checked until the next session (at which point it, too, will be invalidated after use).

The server need not make the effort of deliberately trying to avoid re-assigning random numbers that have been used before: the chance of it happening is so low that even if it did, nobody would know to make use of it.

When a user logs out through some deliberate logout function, their current cookie number is also invalidated. The user also has an option somewhere to clear all persistent logins being remembered by the system, just in case.

Periodically, the database is purged of associations older than a certain time-period (three months, perhaps: the size of the table would be far more an issue than any possibilities of collision in a 128 bit random space).

The following user functions must not be reachable through a cookie-based login, but only through the typing of a valid password:

interface cannot be instantiation

public interface Handler{
public void Hello();

import Handler;
public class OtherParser{
Handler handler;

2) just uses a declaration of the interface, which is different from instiation

public class MyHandler implements Handler{
public void Hellp(){
System.out.println(“my Handler implements”);
Handler handler = new MyHander();


In the case below, Animal is an interface. it uses an anonymous class which is actually a class; that is why it can be instantiated.

Animal animal = new Animal() {
    public void Eat(String name) {
        System.out.printf("Someone ate " + food_name);


static variable can be changed

as long as it is not “final”

public class StaticDemo {
static String name;

public static void staticVariable() {
name = name + ” ” + “Singh”;
System.out.println(“Value of static variable after method calling : ”
+ name);

public static void main(String[] args) {
System.out.println(“Initial value of static variable : ”
+; = “Bharat”;
System.out.println(“Value of static variable after initialization : ”



Initial value of static variable : null
Value of static variable after initialization : Bharat
Value of static variable after method calling : Bharat Singh

reference in java and pointer in C

References might be implemented by storing the address. Usually Java references will be implemented as pointers, but that’s not required by the specification. They may be using an additional layer of indirection to enable easier garbage collection. But in the end it will (almost always) boil down to (C-style) pointers being involved in the implementation of (Java-style) references.

You can’t do pointer arithmetic with references. The most important difference between a pointer in C and a reference in Java is that you can’t actually get to (and manipulate) the underlying value of a reference in Java. In other words: you can’t do pointer arithmetic.

In C you can add something to a pointer (i.e. the address) or substract something to point to things that are “nearby” or point to places that are at any place.

In Java, a reference points to one thing and that thing only. You can make a variable hold a different reference, but you can’t just ask it to point to “the thing after the original thing”.

References are strongly typed. Another difference is that the type of a reference is much more strictly controlled in Java than the type of a pointer is in C. In C you can have an int* and cast it to a char* and just re-interpret the memory at that location. That re-interpretation doesn’t work in Java: you can only interpret the object at the other end of the reference as something that it already is (i.e. you can cast a Object reference to String reference only if the object pointed to is actually a String).

Those differences make C pointers more powerful, but also more dangerous. Both of those possibilities (pointer arithmetic and re-interpreting the values being pointed to) add flexibility to C and are the source of some of the power of the language. But they are also big sources of problems, because if used incorrectly they can easily break assumptions that your code is built around. And it’s pretty easy to use them incorrectly.

java command line option

-cp, -classpath <directories and compressed or .jar files separated by : (; on Windows)>
Sets the search path for application classes and resources. If -classpath and -cp are not used, and the CLASSPATH environment variable is not set, the user classpath is, by default, the current directory (.).
-help, -?
Prints a usage message.