Stopping people loging in twice

[When ideas fail]

Hello, if i am using this generic view in my urls.py?

(r'^accounts/login/$', 'django.contrib.auth.views.login',
{'template_name': 'myapp/login.html'}),

Is there a way i can stopped people who are already logged in logging
in again?

Thanks

[Gaddoz]

I would like to do something like this, too!

Please help!

[Masklinn]

How about simply providing different content if the user is already
logged in (in your template)?

Alternatively, you can create your own decorator (I'd have suggested http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.decorators.user_passes_test
but it redirects to the login page so that's not an option): you
merely need to check if request.user.is_authenticated().

[Brian May]

On Fri, Jul 31, 2009 at 08:04:50AM -0700, When ideas fail wrote:
> Is there a way i can stopped people who are already logged in logging
> in again?

My initial thought - this sounds risky - for a website.

How do you know if the user is already logged in?

The computer they were using may have died, and now they are trying to log in
on another computer. They can't log out on the first computer - it crashed.

Instead they will have to wait for the session to time out.
--
Brian May <br...@microcomaustralia.com.au>

[django user]

I'm interested in a solution for this as well.

I am thinking that a good way might be to rewrite the auth middleware
to check and see if a user login for this user exists and if it does
then remove that login and log in the current user. A message could
then be passed to the login page letting them know that they have
logged in elsewhere and their session at this computer was ended.

I don't know if django has a good way to query if the user is logged
in or not...

[Malcolm Tredinnick]

On Fri, 2009-07-31 at 19:43 -0700, django user wrote:
> I'm interested in a solution for this as well.
>
> I am thinking that a good way might be to rewrite the auth middleware
> to check and see if a user login for this user exists and if it does
> then remove that login and log in the current user. A message could
> then be passed to the login page letting them know that they have
> logged in elsewhere and their session at this computer was ended.

HTTP is a stateless protocol. By design. As has been pointed out in
another reply in this thread, the concept of "already logged in" is
therefore no very well defined. Because it implies there is a concept of
logged out. Which generally doesn't happen. All you can know is that you
have seen a particular session cookie before. However, you are not
guaranteed to know that you will never see a session cookie again in the
future unless the user explicitly tells you to delete it. And that isn't
always possible. What if you have browser-based sessions, so the cookies
expires when the browser is closed. And now the user's browser crashes,
or they shut it down, or their laptop battery runs out? They no longer
have the cookie and so they cannot tell you to remove it. That's just
one of a large number of scenarios in which you are setting things up so
that users will not be able to use your site as a result of fairly
normal behaviour of themselves and their computers.

>
> I don't know if django has a good way to query if the user is logged
> in or not...

You cannot query for session identifiers by username, no.

Regards,
Malcolm

[django user]

So is there a viable django solution for this problem?

On Jul 31, 7:50 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Malcolm Tredinnick]

On Fri, 2009-07-31 at 20:56 -0700, django user wrote:
> So is there a viable django solution for this problem?

You can implement your own session support. It's not that difficult.
Django is just a layer on top of Python, so there's a Django solution to
any computable problem. Django's default contrib.sessions framework,
however, is not going to be useful to you for this problem.

Regards,
Malcolm

[Tim Chase]

> So is there a viable django solution for this problem?

To build on what Malcolm was saying, the problem you have is that
the only things your server knows are (1) when a user last
engaged in a transaction with your server and optionally (2) when
a user has intentionally logged out. #2 is nice, but many users
don't log out intentionally -- like Malcolm said, they just close
the browser or shut down the computer.

In theory, you could create your own session backend that tracks
the user associated with a session token and last-activity
timestamp, and ensure that the user is unique in your session-store.

HOWEVER...this creates a world of hurt for pretty much everybody:

- Testing on multiple browsers becomes a pain because you need to
serialize your tests, or create a user for each browser to step
through the processes in parallel.

- Users get miffed because you break their expectations of how
the web usually works.

- You may have to support those miffed users who call to let you
know they can't log in, peeving them even further when you tell
them "oh, just wait 30 minutes and your session will expire".
You might be able to mitigate this by having a JavaScript
activity-ping on your page that makes a request every 30 seconds
or every minute, and then shortening your timeout window to
5-minutes. However, this peeves the folks that disable JS (such
as the FF NoScript plugin) because they now have to perform
activity every 5 minutes or else re-login. This also puts
notable load on the server (one request per user, every 30-60
seconds, just to update their "hey, I'm still here" timestamp)

I'm sure there are other reasons not to do it, but those are what
I can come up with before breakfast and in my mind, the list is
already pretty convincing against the idea of trying to limit
users to a single session.

The only <sarcasm>value</sarcasm> I could see in this is for some
service where you're charging on a per-user-seat licensing
scheme. If this is your wish, take a hint from little companies
like Salesforce.com -- just do your licensing per-named-user and
stop worrying about how many machines they access it from.

-tim

[djang...@gmail.com]

The main purpose for this would be to track login collisions and make sure users aren't sharing log in info.

If a user has a high number of collisions we can assume they are sharing their credentials and take the appropriate actions.

-- Sent from my Palm Pre

---

[Tim Chase]

> The main purpose for this would be to track login collisions
> and make sure users aren't sharing log in info.
>
> If a user has a high number of collisions we can assume they
> are sharing their credentials and take the appropriate
> actions.

There are plenty of legitimate reasons for login collisions: I
might be using the site from my desktop machine, walk into the
conference room to give a demo of your website on the company
laptop, and then walk out the door to a customer site where I
access the site from my handheld mobile device. My computer may
die (had 4 XP boxes push up daisies this past week in some
fashion or another thanks to hardware failure or driver issues,
out of ~50 I oversee) before I can log out and I need to use
another machine. A user may flip back and forth between browsers
which won't share session information. Things may compound if
you offer an API -- multiple scripts may run that use the same
login (my company has a handful of scripts that all access
salesforce.com's API and can collide)

So rather than pissing off users by *preventing* it, simply log
hinky transactions and if you suspect they are violating your
Terms of Service, fall back on your contractual agreement's
audit-the-customer clause (if you're so fascistly controlling
your users, you do have one, right?). I'm sure they'll love an
audit because it's great for customer relations.

-tkc