Hi,
I have a web application in which I need to restrict user access to 1
session per user. I've done this my creating a cache entry when a user logs
in, and checking on subsequent logins for that entry, and refusing access if
the user is already present.
However, this gives me a problem if the user forgets to log out, as they
then need to wait until the session time out before they can log in again.
I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.
Thanks in advance.
9  1687 
You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.
If you mean client side, you have to emit the JavaScript necessary to cause
a postback.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** ************
Think Outside the Box!
*************** ************
"Simon Smith" wrote: Hi,
I have a web application in which I need to restrict user access to 1
session per user. I've done this my creating a cache entry when a user logs
in, and checking on subsequent logins for that entry, and refusing access if
the user is already present.
However, this gives me a problem if the user forgets to log out, as they
then need to wait until the session time out before they can log in again.
I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.
Thanks in advance.
Sorry if I'm missing the point here, but this answer doesn't seem to have any
relevance to my question.
Can anyone either expand on this answer, or give me an alternative?
Thanks
"Cowboy (Gregory A. Beamer) - MVP" wrote: You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.
If you mean client side, you have to emit the JavaScript necessary to cause
a postback.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** ************
Think Outside the Box!
*************** ************
"Simon Smith" wrote:
Hi,
I have a web application in which I need to restrict user access to 1
session per user. I've done this my creating a cache entry when a user logs
in, and checking on subsequent logins for that entry, and refusing access if
the user is already present.
However, this gives me a problem if the user forgets to log out, as they
then need to wait until the session time out before they can log in again.
I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.
Thanks in advance.
There is something amiss with your requirements. First, your original
requirement is that there is only 1 Session allowed per user. This would
prevent a second user or the same user from loggin in during that Session,
via your mechanism of denying access to another user, or another instance of
the same user.
Now, your client wants you to add another requirement which contradicts the
first: Instead of refusing access to the second user, you kill the first
user Session, and allow access to the second user, effectively hijacking the
first user Session.
You need to inform the client of this contradiction. He can't have it both
ways. Either a user is restricted to a single Session, or the user is not.
If the user does not log out, the user must wait for the Session to end.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:16******** *************** ***********@mic rosoft.com... Sorry if I'm missing the point here, but this answer doesn't seem to have
any
relevance to my question.
Can anyone either expand on this answer, or give me an alternative?
Thanks
"Cowboy (Gregory A. Beamer) - MVP" wrote:
You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.
If you mean client side, you have to emit the JavaScript necessary to
cause
a postback.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** ************
Think Outside the Box!
*************** ************
"Simon Smith" wrote:
> Hi,
>
> I have a web application in which I need to restrict user access to 1
> session per user. I've done this my creating a cache entry when a user
> logs
> in, and checking on subsequent logins for that entry, and refusing
> access if
> the user is already present.
>
> However, this gives me a problem if the user forgets to log out, as
> they
> then need to wait until the session time out before they can log in
> again.
>
> I have been asked by one client if, instead of refusing entry to the
> second
> user login, we can instead automatically kill the first session, then
> successfully log the second user in. Is this possible? I do know the
> session
> ID of the first session, but can't find any way to access a session by
> ID.
>
> Thanks in advance.
The original requirement was to only allow 1 session per user. This is
implemented. However, as I said, if the user forgets to log off and just
browses away or closes the browser, then they are unable to log on again
until the session expires.
What this specific client wants to to limit to 1 session per user. If the
same user tries to log on a second time, then, rather than saying "you are
already logged on", they would prefer us to kill any active sessions for that
user, then create a new session for this new logon. Still one session per
user, as all the older ones are terminated.
This is something that has been recommended to them by a net security
testing firm, not something I particularly want to do. Sounds like a horrible
user experience to me personally...
"Kevin Spencer" wrote: There is something amiss with your requirements. First, your original
requirement is that there is only 1 Session allowed per user. This would
prevent a second user or the same user from loggin in during that Session,
via your mechanism of denying access to another user, or another instance of
the same user.
Now, your client wants you to add another requirement which contradicts the
first: Instead of refusing access to the second user, you kill the first
user Session, and allow access to the second user, effectively hijacking the
first user Session.
You need to inform the client of this contradiction. He can't have it both
ways. Either a user is restricted to a single Session, or the user is not.
If the user does not log out, the user must wait for the Session to end.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:16******** *************** ***********@mic rosoft.com... Sorry if I'm missing the point here, but this answer doesn't seem to have
any
relevance to my question.
Can anyone either expand on this answer, or give me an alternative?
Thanks
"Cowboy (Gregory A. Beamer) - MVP" wrote:
You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.
If you mean client side, you have to emit the JavaScript necessary to
cause
a postback.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** ************
Think Outside the Box!
*************** ************
"Simon Smith" wrote:
> Hi,
>
> I have a web application in which I need to restrict user access to 1
> session per user. I've done this my creating a cache entry when a user
> logs
> in, and checking on subsequent logins for that entry, and refusing
> access if
> the user is already present.
>
> However, this gives me a problem if the user forgets to log out, as
> they
> then need to wait until the session time out before they can log in
> again.
>
> I have been asked by one client if, instead of refusing entry to the
> second
> user login, we can instead automatically kill the first session, then
> successfully log the second user in. Is this possible? I do know the
> session
> ID of the first session, but can't find any way to access a session by
> ID.
>
> Thanks in advance.
Maybe I'm being thick, but why not just abandon the session and create a new
one as the first action when the user pushed the log on button. If its the
first log on then no harm done, and if its a subsequent log on then the
sesion doesn't have any stale data still populating it.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:AF******** *************** ***********@mic rosoft.com... The original requirement was to only allow 1 session per user. This is
implemented. However, as I said, if the user forgets to log off and just
browses away or closes the browser, then they are unable to log on again
until the session expires.
What this specific client wants to to limit to 1 session per user. If the
same user tries to log on a second time, then, rather than saying "you are
already logged on", they would prefer us to kill any active sessions for
that user, then create a new session for this new logon. Still one session per
user, as all the older ones are terminated.
This is something that has been recommended to them by a net security
testing firm, not something I particularly want to do. Sounds like a
horrible user experience to me personally...
"Kevin Spencer" wrote:
There is something amiss with your requirements. First, your original
requirement is that there is only 1 Session allowed per user. This would
prevent a second user or the same user from loggin in during that
Session, via your mechanism of denying access to another user, or another
instance of the same user.
Now, your client wants you to add another requirement which contradicts
the first: Instead of refusing access to the second user, you kill the first
user Session, and allow access to the second user, effectively hijacking
the first user Session.
You need to inform the client of this contradiction. He can't have it
both ways. Either a user is restricted to a single Session, or the user is
not. If the user does not log out, the user must wait for the Session to end.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:16******** *************** ***********@mic rosoft.com... Sorry if I'm missing the point here, but this answer doesn't seem to
have any
relevance to my question.
Can anyone either expand on this answer, or give me an alternative?
Thanks
"Cowboy (Gregory A. Beamer) - MVP" wrote:
> You can create user controls as black boxes and bubble up events
using> delegates. It is rather easy to wire and any page using the control
can> handle the event you throw.
>
> If you mean client side, you have to emit the JavaScript necessary to
> cause
> a postback.
>
> --
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> *************** ************
> Think Outside the Box!
> *************** ************
>
>
> "Simon Smith" wrote:
>
> > Hi,
> >
> > I have a web application in which I need to restrict user access to
1> > session per user. I've done this my creating a cache entry when a
user> > logs
> > in, and checking on subsequent logins for that entry, and refusing
> > access if
> > the user is already present.
> >
> > However, this gives me a problem if the user forgets to log out, as
> > they
> > then need to wait until the session time out before they can log in
> > again.
> >
> > I have been asked by one client if, instead of refusing entry to
the> > second
> > user login, we can instead automatically kill the first session,
then> > successfully log the second user in. Is this possible? I do know
the> > session
> > ID of the first session, but can't find any way to access a session
by> > ID.
> >
> > Thanks in advance.
Well, Simon, in that case, there is no need to do anything with the original
Session. It is unavailable anyway. When they log in again, they are already
in a new Session. Anything in the old Session is history.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:AF******** *************** ***********@mic rosoft.com... The original requirement was to only allow 1 session per user. This is
implemented. However, as I said, if the user forgets to log off and just
browses away or closes the browser, then they are unable to log on again
until the session expires.
What this specific client wants to to limit to 1 session per user. If the
same user tries to log on a second time, then, rather than saying "you are
already logged on", they would prefer us to kill any active sessions for
that
user, then create a new session for this new logon. Still one session per
user, as all the older ones are terminated.
This is something that has been recommended to them by a net security
testing firm, not something I particularly want to do. Sounds like a
horrible
user experience to me personally...
"Kevin Spencer" wrote:
There is something amiss with your requirements. First, your original
requirement is that there is only 1 Session allowed per user. This would
prevent a second user or the same user from loggin in during that
Session,
via your mechanism of denying access to another user, or another instance
of
the same user.
Now, your client wants you to add another requirement which contradicts
the
first: Instead of refusing access to the second user, you kill the first
user Session, and allow access to the second user, effectively hijacking
the
first user Session.
You need to inform the client of this contradiction. He can't have it
both
ways. Either a user is restricted to a single Session, or the user is
not.
If the user does not log out, the user must wait for the Session to end.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:16******** *************** ***********@mic rosoft.com... > Sorry if I'm missing the point here, but this answer doesn't seem to
> have
> any
> relevance to my question.
>
> Can anyone either expand on this answer, or give me an alternative?
>
> Thanks
>
> "Cowboy (Gregory A. Beamer) - MVP" wrote:
>
>> You can create user controls as black boxes and bubble up events using
>> delegates. It is rather easy to wire and any page using the control
>> can
>> handle the event you throw.
>>
>> If you mean client side, you have to emit the JavaScript necessary to
>> cause
>> a postback.
>>
>> --
>> Gregory A. Beamer
>> MVP; MCP: +I, SE, SD, DBA
>>
>> *************** ************
>> Think Outside the Box!
>> *************** ************
>>
>>
>> "Simon Smith" wrote:
>>
>> > Hi,
>> >
>> > I have a web application in which I need to restrict user access to
>> > 1
>> > session per user. I've done this my creating a cache entry when a
>> > user
>> > logs
>> > in, and checking on subsequent logins for that entry, and refusing
>> > access if
>> > the user is already present.
>> >
>> > However, this gives me a problem if the user forgets to log out, as
>> > they
>> > then need to wait until the session time out before they can log in
>> > again.
>> >
>> > I have been asked by one client if, instead of refusing entry to the
>> > second
>> > user login, we can instead automatically kill the first session,
>> > then
>> > successfully log the second user in. Is this possible? I do know the
>> > session
>> > ID of the first session, but can't find any way to access a session
>> > by
>> > ID.
>> >
>> > Thanks in advance.
re: I have been asked by one client if, instead of refusing entry to the second
user login, we can instead automatically kill the first session, then
successfully log the second user in. Is this possible? I do know the session
ID of the first session, but can't find any way to access a session by ID.
You don't need to access a session by ID to do that.
Just include a Session.Abandon command before the client logs in.
If the session for that user's browser is still active, it will be killed.
If the user logs in from another workstation, that won't help, of course.
Juan T. Llibre, ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
Foros de ASP.NET en Español : http://asp.net.do/foros/
=============== =============== ========
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:16******** *************** ***********@mic rosoft.com... Sorry if I'm missing the point here, but this answer doesn't seem to have any
relevance to my question.
Can anyone either expand on this answer, or give me an alternative?
Thanks
"Cowboy (Gregory A. Beamer) - MVP" wrote:
You can create user controls as black boxes and bubble up events using
delegates. It is rather easy to wire and any page using the control can
handle the event you throw.
If you mean client side, you have to emit the JavaScript necessary to cause
a postback.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************** ************
Think Outside the Box!
*************** ************
"Simon Smith" wrote:
> Hi,
>
> I have a web application in which I need to restrict user access to 1
> session per user. I've done this my creating a cache entry when a user logs
> in, and checking on subsequent logins for that entry, and refusing access if
> the user is already present.
>
> However, this gives me a problem if the user forgets to log out, as they
> then need to wait until the session time out before they can log in again.
>
> I have been asked by one client if, instead of refusing entry to the second
> user login, we can instead automatically kill the first session, then
> successfully log the second user in. Is this possible? I do know the session
> ID of the first session, but can't find any way to access a session by ID.
>
> Thanks in advance.
The problem is that I am limiting to 1 session per user purely by storing a
token when a user logs on. So, if they try to log on again (from a different
client) I check for the presence of the token on the server, and deny if it
is present.
If I just delete the token and allow them to log on, then this doesn't do
anything to the original session on the original client; it creates a new
session for this new logon, but the old session is still available and active.
"Kevin Spencer" wrote: Well, Simon, in that case, there is no need to do anything with the original
Session. It is unavailable anyway. When they log in again, they are already
in a new Session. Anything in the old Session is history.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:AF******** *************** ***********@mic rosoft.com... The original requirement was to only allow 1 session per user. This is
implemented. However, as I said, if the user forgets to log off and just
browses away or closes the browser, then they are unable to log on again
until the session expires.
What this specific client wants to to limit to 1 session per user. If the
same user tries to log on a second time, then, rather than saying "you are
already logged on", they would prefer us to kill any active sessions for
that
user, then create a new session for this new logon. Still one session per
user, as all the older ones are terminated.
This is something that has been recommended to them by a net security
testing firm, not something I particularly want to do. Sounds like a
horrible
user experience to me personally...
"Kevin Spencer" wrote:
Sounds like your client is a control freak who
feels the need to nanny his numbskull employees.
;-)
A little user education would work wonders here.
Your client should instruct his employees not
to login twice from different workstations.
Quite simple.
Juan T. Llibre, ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
Foros de ASP.NET en Español : http://asp.net.do/foros/
=============== =============== ========
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:53******** *************** ***********@mic rosoft.com... The problem is that I am limiting to 1 session per user purely by storing a
token when a user logs on. So, if they try to log on again (from a different
client) I check for the presence of the token on the server, and deny if it
is present.
If I just delete the token and allow them to log on, then this doesn't do
anything to the original session on the original client; it creates a new
session for this new logon, but the old session is still available and active.
"Kevin Spencer" wrote:
Well, Simon, in that case, there is no need to do anything with the original
Session. It is unavailable anyway. When they log in again, they are already
in a new Session. Anything in the old Session is history.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
"Simon Smith" <Si********@dis cussions.micros oft.com> wrote in message
news:AF******** *************** ***********@mic rosoft.com... > The original requirement was to only allow 1 session per user. This is
> implemented. However, as I said, if the user forgets to log off and just
> browses away or closes the browser, then they are unable to log on again
> until the session expires.
>
> What this specific client wants to to limit to 1 session per user. If the
> same user tries to log on a second time, then, rather than saying "you are
> already logged on", they would prefer us to kill any active sessions for
> that
> user, then create a new session for this new logon. Still one session per
> user, as all the older ones are terminated.
>
> This is something that has been recommended to them by a net security
> testing firm, not something I particularly want to do. Sounds like a
> horrible
> user experience to me personally...
>
> "Kevin Spencer" wrote:
> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: mrbog |
last post by:
Tell me if my assertion is wrong here:
The only way to prevent session hijacking is to NEVER store
authentication information (such as name/password) in the session.
Well, to never authenticate a user from information you got from the
session. Each secure app on a site must challenge the user for name
and password, each and every time the user accesses it (not just once
and then store it in the session). If a secure app is multi-page,...
|
by: Erik Johnson |
last post by:
There are a lot of things about PHP I was not too keen on and hence why
my company is primarily doing Python these days, but one thing I was quite
impressed with was the ease with which it provided session functionality...
<?php
session_start();
session_register;
$my_var = "whatever";
|
by: Abhilash.k.m |
last post by:
This is regarding the session management using Out of
proc session management(SQL SERVER). Among the samples
below which one is better to set the session?
1. There are 20 session variables and all of them
are being stored into session and accessed from session
and individual session object. Example: Session
= "XYZ", Session=100, Session="NAME", etc.
|
by: John A Grandy |
last post by:
for high traffic public websites , what are the proven options for
session-state storage & management ?
is an out-of-process state-server generally preferred over a sql-server ?
what are the relevant criteria ? is the primary criteria max expected total
storage size (for all active sessions) versus max ram available on the
state-server machine ?
if ADO.NET objects (such as small DataTables) must be stored in
session-state , is any...
|
by: James Hunter Ross |
last post by:
We love the ASP.NET "Session" concept and make good use of it. But, getting
close to deployment we find we lose sessions far too often, probably due to
application restarts, etc. We hope to eliminate these restarts, but we're
not sure that can be achieved. (We are exploring who/what might be touching
web.config or assemblies or other files in our application, but have found
nothing so far.)
We have some serious rewriting to do if all...
| | |
by: BillE |
last post by:
When a user opens a new IE browser window using File-New-Window the
integrity of an application which relies on session state is COMPLETELY
undermined. Anyone who overlooks the fact that File-New-Window creates an
instance of IE in the same process with the same SessionID as the parent
window is in big trouble. This fundamentally restricts the usefullness of
using session state management.
I probably missed it somewhere - can...
|
by: rug |
last post by:
Hello,
I want to use a MySQL Heap table (server load isn't an issue) for session management considering that I use a shared server and don't want anyone who has access to /tmp to be able to read session data and possibly hijack a session.
I've got no clue how to use a table for session management.
I've started off by creating a table that will store the following:
Session ID (will create this using dechex with a random number)...
|
by: =?Utf-8?B?YW5vb3A=?= |
last post by:
Hello,
I am developing a Simple ASP Application with a Login page. I
want to know how session ID can be generated after User has authenticated
instead of generation along with the Login page request. Also Session ID must
be unique each time the user logs in. This is required so that Session
Hijacking and Session Fixation could be prevented. Should I have to use other
process instead of General ASP Session Management. Please Help
Thank...
|
by: knyghtfyre |
last post by:
Hello,
My company is developing a rather large application with .NET 2.0. We
are expanding to a server farm and are in the process of converting
our application to use an out-of-process session state management with
SQL Server.
We have ran into a problem with the Session_onEnd event. We know it's
not supposed to fire when in an out-of-process mode, but we have a
large amount of code that must be executed to clean the session and to
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
