How to manage Session in WSO2 IS 5.0.0 + SP01

Please note that the configurations and the post below applies only for WSO2 IS 5.0.0 + SP01

In authentication framework logged in session for a user is maintained with the commonAuthId session cookie in the SessionContextCache(AppAuthFrameworkSessionContextCache).
By default no expiration time is set to the commonAuthId cookie and the cache gets invalidated by 15 minutes which is the default cache invalidate time. This cache expiary time is hard coded in org.wso2.carbon.caching.impl.CacheImpl. Thus,
it's not configurable at the moment.
So this makes the idle timeout for the logged in session as 15 minutes which is not configurable.
Further, following configurations are available to manage logged in session timeout in identity.xml under Server.JDBCPersistenceManager configuration block.
We can enable session data persistence with below.

<SessionDataPersist>
<...>...<...>
<Enable>true</Enable>
<...>...<...>
</SessionDataPersist>

This indicates to store session data associated with the logged in session.
Session data persistence comes with a cleanup service configuration that removes stale sessions.

<SessionDataPersist>
<...>...<...>
<CleanUp>
<Enable>true</Enable>
<Period>10</Period>
<TimeOut>60</TimeOut>
</CleanUp>
<...>...<...>
</SessionDataPersist>

Cleanup service gets executed only if it is enabled with SessionDataPersist.CleanUp.Enable.
SessionDataPersist.CleanUp.Period defines the time period among two consecutive cleanups in minutes. By default it is 1 day.
SessionDataPersist.CleanUp.TimeOut defines the timeout value of session data in minutes. By default it is two weeks.
For an example if we consider the above configuration it means that the clean up task will run periodically with a period of 10 minutes.
And in a cleanup process it will remove all session data persisted before 60 minutes.

Remember me time period can be configured as below.

<SessionDataPersist>
<...>...<...>
<RememberMePeriod>60</RememberMePeriod>
<...>...<...>
</SessionDataPersist>

Configuring above will set the expire time for the commonAuthId cookie only if remember me option is selected when user logs in. So as per above configuration the expiration time for the commonAuthId cookie is 60 minutes.
By default if remember me option is selected the cookie expiration time is set to two weeks.
Thus, the browser will expire the cookie after this much of time.
Further, if the logged in session is invalidated from the cache, it will be restored back to the cache, if and only if the remember me option is selected. Thus, no matter that session data persistence is enabled if remember me option is not selected the idle time out of the logged in session becomes 15 minutes which is the default cache invalidate time.

In addition below configurations are possible as well under <SessionDataPersist>.

SessionDataPersist.Only
Setting this to true will disable caching and session data will only be persisted. Thus, session data will be available only if the user has selected remember me option when login. Otherwise even though session data is persisted it's not retrieved.
This also disables caching in AthenticationContextCache and AuthenticationResultCache as well.

SessionDataPersist.Temporary
Setting this property to true will store data added to AuthenticationContextCache and AuthenticationResultCache as well.
In a cache hit if entry is not found data will be retrieved from the session persistence store

I will update the post on how to test session timeout later. :)

How to solve conflicts in Git Pull Requests

Github allows people to collaborate and be more productive. One such way of collaborating is Pull Requests. It let us to tell others about that changes that we want to merge for a specific repository on Github.
The recommended way is to first fork the repo that you want to contribute. Then clone the forked repo. Create a branch and add commits to that branch. Then push your commits to the remote repo that you forked. If there are changes between our branch and upstream branch Github allows us to open a pull request.

You can find more information about forking, cloning, branching etc. from the Github documentation .

Here, I'm going a one step ahead.
Sometimes when you have created a pull request Github will report that there are merge conflicts in the pull request that you created. This happens because in both the upstream and your branch same files have been changed in the same point making it difficult for Github to merge by itself. In this case we have to resolve the conflicts manually.

It's just a matter of following steps below. :)

1. First fetch the upstream
git fetch upstream

2. Switch to the master branch
git checkout master

3. Merge the fetched upstream to the master branch
git merge upstream/master

4. Switch to the branch that you did developing stuff
git checkout <your_branch>

5. Merge the master with your branch
git merge master

Here you will see if there are merge conflicts

6. Solve the conflicts with git mergetool
We can solve the conflicts with Meld
For that we just have to give the tool type to the git mergetool command as below.
git mergetool -t meld

This will open up the merge window with three columns.
The left most shows your local working copy as LOCAL.
The right most shows the remote branch change to be merged as REMOTE.
The middle one is the half finished merge which is the BASE. This is one which is finally going to be saved. So you have to merge changes from the LOCAL and the REMOTE to the BASE.

7. Then commit all changes.
git commit -m "Commit message"

8. Finally push commits to your remote repo.
git push origin <your_branch>

Hope this would help.