[dev-neuridia] dev Digest, Vol 2, Issue 10

[Anthony Levensalor]

> Today's Topics:
>
>    1. A Problem Scenario (Muizudeen Kusimo)
>    2. A Problem Scenario - User Names & Passwords (Muizudeen Kusimo)
>    3. Re: A Problem Scenario (Charles A. Landemaine)
>    4. IMAP4, search, and CPU usage (Charles A. Landemaine)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Mar 2008 01:08:37 -0700 (PDT)
> From: Muizudeen Kusimo <muizz at inspaya.com>
> Subject: [dev-neuridia] A Problem Scenario
> To: dev at lists.neuridia.org
> Message-ID: <324892.18506.qm at web55312.mail.re4.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello Anthony,
>
>   
>> I don't think that's something we're interested in worrying about, it's 
>> the user's machine, and if they want to log in from Netscape and Firefox 
>> at the same time, or from the same browser twice concurrently, I don't 
>> know why that would be a problem. Let's chat on this some more.
>>     
>
> In this part of the world, many people make use of Cyber Cafe's because it's often cheaper to do so. A typical scenario will have two friends (Bola and Ade) both sitting at a computer system having only IE (maybe vs 5, 6 or 7) and both of them attempt logging in to Nueridia via different browser windows or tabs just to save limited time/money.
>   
This is something that I find to be a good thing, and I would certainly 
hope Neuridia would not want to be booting either of them off the way 
AOL does when I start Pidgin. If we can handle managing to keep their 
sessions separate and maybe use a different type of session persistence 
in the case of the second, third, etc login, I think that having the 
ability to have multiple people logged in would be abenefit more than a 
detriment, and would set us apart, rather than hinder us or make us look 
bad.

> If this happens on Yahoo! Mail for example, the email system logs both of them out (because they are using the same User Agent and the same machine) and prompts the person who logged in first to VERIFY his/her password.
>   
Ok, this I haven't seen, only because all my passwords are stored and 
I'm not familiar with the usage of public terminals for email access, 
have just never had the opportunity.
> If we leave this unchecked, our email system may be perceived as buggy because browsers respond to this situation differently.
>   
Here's my philosophy on individual browsers acting silly. When they do, 
I take whatever it is I am doing, I stream it into a different 
mechanism, and I make it work better than it would have. When we talk 
about this session stuff, we are talking about a fairly decent amount of 
data being stored. We're planning on frontloading quite a bit to the 
client's caching mechanisms for indexing and speedy performance.

But, and this is a big but, if the client side does not prove viable or 
is slower than the methods I know we can utilize on the server side, 
then functions that do not get a benefit from the way we're planning it 
will be changed and evolved into methods that work more toward the 
community's ideal.

Great fun, either way.

Perhaps we will entertain asking them what behavior they want via an 
"are you on a public terminal" question, etc.

Truthfully, I find the idea of automatically barring the behavior to be 
too heavy-handed to fit in with the vision of Neuridia as an efficient, 
freindly app that will do it's job and let you do yours. This is 
optional behavior for the user to decide, IMHO, or at least the site admin.

> There is a proof-of-concept demo here http://www.inspaya.com/client-projects/for_tope/
>   
Sure, we _could_ do this. It would be simple to check for the cookie we 
would place on their machine and reject logins from mismatched keys / 
Session IDs / GUIDs, whichever we liked.

We've decided that for V1.0 of Neuridia, we are not going to time our 
users out or boot them off. This is going to be open source, though, 
with excellent API documentation, and the beginnings of a plugin API. I 
am certain that over time everyone can have precisely what they want 
from the application we're intending to deliver, definitely. :)

Now, that is not to say I am wholly inflexible on this one. I think that 
the potential for issues as the session cookies crossed merits this 
while topic a mention and a sketch in when we do the next cycle's roadmap.

~Ant
> I have tested in Firefox, Opera, IE and emulated Netscape.
>  
>   
Definitely does, no once can fault you there. :)
~Ant
> [snip
>   

> Hello Again,
>
> Sorry, I forgot to include the user names and passwords.
>
> They are:
>
> user1, pass1
> user2, pass2
> user3, pass3
>
> You can try any of these combinations on the URL below.
>
>   
Thanks, I was awfully confused there for a minute, had to go back and 
delete the question asking where the logins were placed. :)


All the best,
~Ant