Hi Jose,

Originally taken from UniData there is a special subroutine that is run each time a UniObjects connection is opened called UOLOGIN.

You can use UOLOGIN to deny a login, you would need to write your own code in the subroutine to decide if a connection is allowed or not.

Although originally designed to control access, you can add other functionality sometimes done via a LOGIN paragraph as well.

The UOLOGIN subroutine

The UOLOGIN subroutine can be used for security purposes to control access to UniVerse accounts on the server. UniObjects, UniObjects for .NET, UniObjects for Java, and InterCall can check for the existence of a UOLOGIN BASIC subroutine on the server. The subroutine has all the capabilities available in UniVerse BASIC so the program can be tailored to meet the needs of the specific environment.

Once the UOLOGIN subroutine is cataloged globally, it will be executed when a client connection is initiated and the connection will fail if the requirements specified in the subroutine are not met. A return value of 0 indicates the requirements have not been met, and a return value of 80011 will be sent to the client.

The UOLOGIN subroutine on the server should contain two arguments, as follows:

SUBROUTINE UOLOGIN(RTNVAL, APPNAME)
If RTNVAL is a set to a nonzero value, the connection is allowed. If RTNVAL is 0, the connection is not allowed and an error message is returned.
APPNAME is the name of the client application trying to establish the connection

Regards,

Hi José, 

Have you considered connection pool licenses for the web applications?  These are tallied separately from the standard (interactive) licenses, and thus increased web traffic will not affect the number of standard licenses available to the "interactive" users.

Other benefits of connection pools include

• keeping the pooled connections open across requests, yielding higher throughput and lower latency
  
• limiting the number of database resources assigned to web traffic, thus protecting the data server from unexpected spikes in web traffic
  

In a prior version of our web software, a client requested that there be only a set number of logins per user. We wrote a program that ran a LISTU and parsed the results and compared it to the current login. If they had exceeded the magic number of logins, they were sent a message that they were being logged off for exceeding the maximum number of users.

Posted: 10-19-2023 17:34

Hello,

With reference to Jonathan's answer, and based on my own testing of UOLIGIN in Universe, the APPNAME parameter of UOLOGIN does not contain the name of the application. Rather it contains the string that precedes the user name in the "user" property of the connection.

For example, in creating a uopy connection:

conn = uopy.connect(host='aixHostName',user='userkey:aixUserName',password='aixUserPassword',account='uvAccountName')

The APPNAME parameter will contain the value "userkey". When the user name is not formatted this way APPNAME is an empty string.

Another example, in configuring the userId parameter for Web DE in JavaScheduler.ini:

userId=key:user

will cause the key to be passed to UOLOGIN in the APPNAME parameter,