Session management

Warning

The following functionality is deprecated and will be removed in a future version.

Some operations use the identity of a memoQ user and complete authorization to check if the user has permissions to perform the actions. In order to validate the identity of the user, memoQ server and the API services employ sessions. A session is created through explicit login and is terminated in case of either explicit logout or session expiry. The login and logout functions are exposed by the security service. The login function requires a user name (as used in memoQ, the UserName field of UserInfo) and a password hash. This function returns a sting, which is the session identifier. This identifier is unique to this session and is valid only while the session is valid (i.e. until logout or session expiry). This session identifier must be specified as input parameters for the functions that require an existing user session. These functions verify the session identifier and report error if the session is invalid.

The caller must store the session identifier and reuse it for subsequent calls. It is not recommended to use a session for a single call and terminate the session afterwards. The session identifier should be cached by the caller and be reused while it is valid. The caller must also pay attention to the session expiry as detailed below.

The session must be terminated after it is no longer used. The logout function terminates the session explicitly. If the session is not terminated explicitly but is not used for more than 2 hours (no operations are initiated in the name of the user) the session is invalidated automatically. Please note that no notification is available when this happens. The caller will discovers an invalidated session the next time the session identifier is used. An error will be reported in this case.

Two types of faults are used in conjunction with sessions. An InvalidSessionIdFault signals that the specified session identifier is not valid or has expired, and an UnauthorizedAccessFault is used to report that the user has no rights to perform the requested operation. (This is not the fault of the caller; this error should be reported to the user.)

Password management

The Password field of the UserInfo class represents the password hash of the user. For security reasons the original password is never sent on the network. Instead, a salted SHA1 algorithm based hash is to be used (with the UserInfo parameter of the CreateUser and UpdateUser operations). The pseudo code of the algorithm is the following:

UserInfo userInfo;
string password = <password entered by the user>;
const string salt = "fgad s d f sgds g  sdg gfdg" ;
byte[] bytesToHash = Encoding.UTF8.GetBytes(password + salt);
HashAlgorithm algorithm = SHA1.Create();
byte[] hash = algorithm.ComputeHash(bytesToHash);
userInfo.Password = ByteArrayToHexString(hash);

The ByteArrayToHexString is a function that should create a string representation of a byte array: e.g. "0AFF0B” for {10, 255, 11}.

In .NET C# there is a simple way to create the hash:

const string salt = "fgad s d f sgds g  sdg gfdg";

public static string HashPassword(string password)
{
return System.Web.Security.
	FormsAuthentication.HashPasswordForStoringInConfigFile(password 	+ 	salt, "sha1");
}

void CreateUser(..., string passwordFromUser)
{
	UserInfo userInfo = new UserInfo();
	...
	userInfo.Password = HashPassword(passwordFromUser);
	...
}

A demo implementation of the ByteArrayToHexString function in C#:

public string ByteArrayToHexString(byte[] b)
{
    StringBuilder sb = new StringBuilder(b.Length * 2);
    for (int i = 0; i < b.Length; i++)
    {
        int v = b[i] & 0xff;
        sb.Append(v.ToString("X2"));
    }
    return sb.ToString().ToUpper();
}