Re: How to check with multiple login?

From: Mark D Powell <Mark.Powell2_at_hp.com>
Date: Thu, 23 Sep 2010 06:57:38 -0700 (PDT)
Message-ID: <f076932c-5a4c-46f9-97d4-141557d88be8_at_h25g2000vba.googlegroups.com>



On Sep 22, 3:10 am, Frank van Bortel <fbor..._at_home.nl> wrote:
> On 09/21/2010 05:06 PM, Mladen Gogala wrote:
>
>
>
>
>
> > On Tue, 21 Sep 2010 01:50:40 -0700, Mullin Yu wrote:
>
> >> I have an application and those user accounts are application users, not
> >> database users, i.e. userid and password stored on the user table (e..g
> >> usr_user).
>
> >> Now, I would like to check with any multiple login of users (same
> >> machine or another user) and in case having, the application will warn
> >> the user and not allow further login.
>
> >> Currently, I think of checking with V$session. But then, may need to set
> >> the value of user id when user logins to the application.
>
> >> Is it possbile and any information can be shared?
>
> > You can use resource limits and set sessions_per_user in create/alter
> > profile statement.
>
> Not if I understand "application users" correctly: there will
> be only one account that actually connects (application_owner)
> and all standard security is ignored.
> There will be only one user session.
>
> Your approach is valid when combined with proxy users. Still
> one application owner user from the middle tier...
>
> --
>
> Regards,
>
> Frank van Bortel- Hide quoted text -
>
> - Show quoted text -

I think "There will be only one user session" should be stated more like "to the database there will be only one Oracle username in use which will be used to open multiple Oracle sessions for the application"

Using dbms_application_info to identify the real end user for the session may or may not be an option depending on if connection pooling is in use. When connection pooling is in use then since every SQL statement issued by a user can be assigned to any open pooled session then dbms_application_info is no longer reliable for this purpose.

HTH -- Mark D Powell -- Received on Thu Sep 23 2010 - 08:57:38 CDT

Original text of this message