Friday, July 25, 2008

Session Invalidation

Session is the user's key to the application. Once the user logs out of the application, it is very vital to invalidate the session.

I have come across a situation where the session was not invalidated even when I clicked on the Logout button.

This happened to me with the NetGear Wireless router that I use. I logged into the Router Management page and clicked on the logout button present. I was presented with the logged out screen. All was well till I wanted to visit the Management console again. When I accessed the pages, I was presented with the console without prompting for username/password.

Did I do something wrong? May be. Retry again. But it still shows the same. I use Firefox as the default browser. Then I tried with Internet Explorer. This is where the magic came up.



The logout button sends back to logged out confirmation page and this relies on the java script to close the browser. But that javascript fails in Firefox. There are 2 trivial things here:

1. To rely on the javascript to close the browser and not verifying the cross browser functionality.
2. Not invalidating the session once you click on the Logout button.

Now talking about why it is important to invalidate the session once the user clicks on the logout button:


1. Memory utilization: Most of the times, username is not the only data stored in the Session object. There could be some user specific cache that can be put into the sessions as well. The cache could account to good amount of memory. Imagine thousands of sessions created on the server which are waiting to be cleaned up and the memory they could could be hogging.

2. Security Vulnerability: Well, this is kind of tricky. Lets say the user has clicked on the logout button but the application has not invalidated the session. Now, there is some window between the user clicking on the logout and the session invalidated on the server side due to timeout. Now, lets take a session stealing case. This scenario leads to an extra time window which will help the other guy to use the stolen session and change the system. Invalidating the session once the user has logged out would reduce that security risk.

Tuesday, July 22, 2008

ORA-12519 & ORA-12505

java.sql.SQLException: Listener refused the connection with the following error:

ORA-12519, TNS:no appropriate service handler found The Connection descriptor used by the client was: localhost:1521:XE

Alright, another Oracle Exception. It says "Listener refused the connection". Is hostname correct? Yes, port? Yes, SID? Yes. Damn me. Must have forgot to start the TNSListener. But wait, if it is saying Listener refused the connection, doesn't it mean that the Listener is working and has refused the connection? Oh, yes. A quick check in the services shows that the Listener is already up and running. Why would Listener refuse the connection.? Wouldn't it refuse if the Oracle service is not running? Yes!! But the Oracle Server is running. Run a quick check and see what it says when the Oracle Service is not running.

Well, it says

java.sql.SQLException: Listener refused the connection with the following error:

ORA-12505, TNS:listener does not currently know of SID given in connect descriptor The Connection descriptor used by the client was: localhost:1521:XE

This clearly states that the SID is not recognized as the service is not running. So the earlier problem was not due to Oracle service not running. Back to square one. Okay, let me see if listener recognizes the Oracle services... What was the command? Oh, Yes. "LSNRCTL.EXE". Do a lsnrctl.exe services

Service "xe" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...

Handler(s): "DEDICATED" established:243 refused:0
state:ready
LOCAL SERVER

The listener is able to identify that there is a service running. Hmmm. Now why does the listener refuse the connection? Let me do a quick restart on both the Oracle Service and Listener service. No use...

Hmmm. Does it have have anything to do with the username/pwd that I am using. Given the fact that the username/pwd has been created just now...It might be.

Now rerun with the root username/pwd. :-) It still fails. Thank God, I have not misconfigured the username/pwd. Wait, I see that there are some connections already established in the Application Server. Well, if its failing, it should fail for all the connections. Do a restart on the AppServer and check. Its the same thing again.

Okay, lets put up a simple java client which will try to create connections and see. Alright, it gets the connection. Let me try to check how many connections it can establish.

Connection :0
Connection
:1
Connection :2
Connection :3
Connection :4
Connection :5
Connection :6
Connection :7
Connection :8
Connection :9
Connection :10
Connection :11
Connection
:12
Connection :13
Connection
:14
Connection :15
Connection :16
Connection :17
Connection :18
Connection
:19
Exception in thread "main" java.sql.SQLException: Listener refused the connection with the following error:
ORA-12519, TNS:no appropriate service handler found The Connection descriptor used by the client was: localhost:1521:XE

Aha!!!! Trying to establish more than 20 connections is causing the problem.

Alright, its out of my control now. Googling, finally I land up at:

http://forums.oracle.com/forums/thread.jspa?messageID=1145120

It says, the problem is with the number of process count defined in the init.ora file. Let me check. There is no process count defined. WTH, let me define the process count in init.ora file and restart Oracle

processes=200

It still stays the same. So adding the process count is not recognized. Let me try what was suggested.

ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE

Now with this change and restarting the Oracle service, it is able to create upto 409 connections now. Great!