Is it possible to monitor pre-login handshake proccess initialized by GlassFish web container

[Former Member]

Hi, I'm developing JSF web application using Sybase Anywhere 12.0.1 and GlassFish web container. I've properly configured connection pool on GlassFish server side. By now, everything works fine. I'm able to login to database (authenticate) and make queries, inserts, updates (using JPA). My question is - whether it is possible to monitor pre-login handshake proccess initialized by GlassFish server? What for? I would like to log/save in database unsuccessful login trials. By now, these issuses are logged in GlassFish log file.

[VolkerBarth]

You can log failed connect attempts with the help of an event of type ConnectFailed.

There's a sample "SecurityCheck" within the v12.0.1 doc set:

Trigger conditions for events

An alternative might be to use auditing to report failing connects.

[Former Member]

Thanks for your reply. But... When I set up connection pool I have to use a user/database login which establishes and manages the pool. Web container uses the user/dbLogin (ConPoolUser) to check and compare in a certain database table (T) password hashes: signed to a certain user and the one which is computed by web container while user tries to login. From Audit I can only know that: (ConPoolUser) Checking Select permission on (T) - OK. If hashes are equal, a user grants connection to database and I'm able to see "Auditing message" = "User xxx invoking DBTRAN". No information while the user failed to connect earlier.

[VolkerBarth]

Hm, I do not understand fully:

Do your users use

• their own database credentials to login (so you are relying on the database engine to check the credentials),
• or do they login with the same (valid) database credentials (specified in the connection string used for pooling) and then have to identify against an application-specific user-management?

If my understanding is correct, the latter seems to be true (with table T). In that case, from the database point of view, each connection would succeed, and the authentification is an application-specific task which you could handle (and report errors) within a login_procedure.

Here's a snippet of code to do so, assuming fnCanAuthenticate() would be a user-defined function to check whether the application-specific credentials are fitting and then return <> 0. In case the application-specific credentials would not fit, then the database would simulate a real login failure, which you could report with the mentioned facilities (ConnectFailed event and/or auditing, methinks), possibly using part of the AppInfo connection parameters to identify the user:

create procedure "DBA".STP_Login()
begin
   declare EXC_INVALID_LOGON exception for sqlstate '28000';
   if current user = 'ConPoolUser' then
      if fnCanAuthenticate(<myrealusername>, MyPwdHash) = 0 then
         signal INVALID_LOGON;
      else
         call sp_login_environment;
      end if;
   else
      -- default path
      call sp_login_environment;
   end if;
end;

grant execute on "DBA".STP_Login to PUBLIC;

set option PUBLIC.Login_procedure='DBA.STP_Login';