Sqwebmail bug?

View: New views
9 Messages — Rating Filter:   Alert me  

Sqwebmail bug?

by Enda Cronnolly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The sqwebmail login has a checkbox which is checked by default, which says
"disable logins from other computers while I am connected".

To me this means, if I am logged in, nobody else can log into my account
from another IP address. Yet, I can do exactly this, but logging in from a
second IP address logs out the person currently logged in on the first IP
address.

I am running a complete courier-mta system, version 0.56

 -Enda.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

Re: Sqwebmail bug?

by Sam Varshavchik :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Enda writes:

> The sqwebmail login has a checkbox which is checked by default, which says
> "disable logins from other computers while I am connected".

There's no such message on the login screen. The only two options are
"Restrict access to your IP address only (increased security)", and
"Accessing from a public machine (enables short idle timeout)".

> To me this means, if I am logged in, nobody else can log into my account
> from another IP address. Yet, I can do exactly this, but logging in from a
> second IP address logs out the person currently logged in on the first IP
> address.

That's exactly how it should work. HTTP is a stateless protocol. There is no
mechanism by which a web server can possibly detect that you have closed
your web browser. Therefore, if a login request is received fro a different
machine, the choices are:

1) To terminate the older login, and accept the new one.

2) To refuse the new login request until a lengthy timeout period has
expired, without receiving any HTTP request for the active login session. If
your PC crashed, you had to reboot, and were assigned a new IP address by
your Internet provider -- tough luck, wait a few hours before you can read
your webmail again.

So, which one makes more sense to you?




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

attachment0 (204 bytes) Download Attachment

Re: Sqwebmail bug?

by Enda Cronnolly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Sam wrote:
>Enda writes:
>> The sqwebmail login has a checkbox which is checked by default, which
>> says
>> "disable logins from other computers while I am connected".
>
> There's no such message on the login screen. The only two options are
> "Restrict access to your IP address only (increased security)", and
> "Accessing from a public machine (enables short idle timeout)".

Ok, that must have been re-written by me for my very non technical userbase
who wouldn't know what an IP address is.

>> To me this means, if I am logged in, nobody else can log into my account
>> from another IP address. Yet, I can do exactly this, but logging in from
>> a
>> second IP address logs out the person currently logged in on the first IP
>> address.
>
> That's exactly how it should work. HTTP is a stateless protocol. There is
> no
> mechanism by which a web server can possibly detect that you have closed
> your web browser. Therefore, if a login request is received fro a
> different
> machine, the choices are:
>
> 1) To terminate the older login, and accept the new one.
>
> 2) To refuse the new login request until a lengthy timeout period has
> expired, without receiving any HTTP request for the active login session.
> If
> your PC crashed, you had to reboot, and were assigned a new IP address by
> your Internet provider -- tough luck, wait a few hours before you can read
> your webmail again.
>
> So, which one makes more sense to you?

Yes Sam, you're spot on there, and made the correct design choice. The
problem lay in my interpretation of your text.

In the back of my mind, I'm toying with the idea of putting some resources
into sqwebmail, eg, gui modernisation, search facility. Not sure if you are
interested in having those put back into the project or not. If I did, I
could actually fix this problem with the use of frames, turn the idle
timeout right down, have a small auto reloading frame maintain the login
state for so long as the browser window is open to reload that frame.

Would submissions like that be welcomed back into the project?

 -Enda.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

Re: Sqwebmail bug?

by Sam Varshavchik :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Enda writes:

> In the back of my mind, I'm toying with the idea of putting some resources
> into sqwebmail, eg, gui modernisation, search facility. Not sure if you are
> interested in having those put back into the project or not. If I did, I
> could actually fix this problem with the use of frames, turn the idle
> timeout right down, have a small auto reloading frame maintain the login
> state for so long as the browser window is open to reload that frame.

I'm fairly sure this is already done, at least in the current version of
sqwebmail.

> Would submissions like that be welcomed back into the project?

A search function would certainly be a good addition, however I don't think
you realize the complexity of such a task. This is more than just searching
for a text string in a file. Once you realize that you need to deal with
MIME decoding, and mapping character sets, this quickly becomes rather
hairy. Although the existing code base already has the library routines for
doing all that, putting all the necessary bits together is going to get
rather tedious.

A fast search function is suprisingly difficult to implement. Case in point:
Google.




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

attachment0 (204 bytes) Download Attachment

Re: Sqwebmail bug?

by Roger B.A. Klorese :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Enda wrote:

>> That's exactly how it should work. HTTP is a stateless protocol. There is
>> no
>> mechanism by which a web server can possibly detect that you have closed
>> your web browser. Therefore, if a login request is received fro a
>> different
>> machine, the choices are:
>>
>> 1) To terminate the older login, and accept the new one.
>>
>> 2) To refuse the new login request until a lengthy timeout period has
>> expired, without receiving any HTTP request for the active login session.
>> If
>> your PC crashed, you had to reboot, and were assigned a new IP address by
>> your Internet provider -- tough luck, wait a few hours before you can read
>> your webmail again.
>>
>> So, which one makes more sense to you?
>>    
>
> Yes Sam, you're spot on there, and made the correct design choice. The
> problem lay in my interpretation of your text.
>  

But that's not what those words mean to the likely naive user.  
"Disconnect other sessions for this user, if active" means what you
intend.  "Restrict access" seems to mean not to allow access to another
IP address AFTER THIS LOGIN.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

Sqwebmail changes - was Re: Sqwebmail bug?

by Enda Cronnolly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sam wrote:

> Enda writes:
>
>> In the back of my mind, I'm toying with the idea of putting some
>> resources
>> into sqwebmail, eg, gui modernisation, search facility. Not sure if you
>> are
>> interested in having those put back into the project or not. If I did, I
>> could actually fix this problem with the use of frames, turn the idle
>> timeout right down, have a small auto reloading frame maintain the login
>> state for so long as the browser window is open to reload that frame.
>
> I'm fairly sure this is already done, at least in the current version of
> sqwebmail.

Will be upgrading to a new hardware setup very shortly and will check this
out, until then I'll be leaving the current deployment as is bar some
security hole pops up.

>> Would submissions like that be welcomed back into the project?
>
> A search function would certainly be a good addition, however I don't
> think
> you realize the complexity of such a task. This is more than just
> searching
> for a text string in a file. Once you realize that you need to deal with
> MIME decoding, and mapping character sets, this quickly becomes rather
> hairy. Although the existing code base already has the library routines
> for
> doing all that, putting all the necessary bits together is going to get
> rather tedious.

The tedious nature of it isn't a problem, the task in hand right now is the
development of a complete spec. MIME decoding is fine and apparent,
character set mapping certainly hadn't occured to me.

> A fast search function is suprisingly difficult to implement. Case in
> point:
> Google.

The strategy I was going for was to databse index the textual content of a
Maildir, and to use a FAM based agent to keep the index current. That has
inherent complexities too for content deletions which I'm working around in
my head, and the linking of a file to a search results page needs me to look
closer at how sqwebmail lists folder content, but that is a relatively
trivial task the only "newness" being that sqwebmail currently displays
listings from a single maildir folder and not cross folder listings which a
search results page would require.

The other functionality change which I think would be worthwhile is to add
identity configuration in the preferences, allowing users to edit their
display name, allow users to add email addresses eg, aliases or fetchmail
retrieved content and its associated changes back to the message composition
page (drop down to select "from" identity, with a default).

Sqwebmail is a wonderfully fast email browser, and for all its differences
to other webmail clients, I don't get user complaints about it at all except
from techie users who want search capabilities and those guys are savvy
enough to integrate themselves with gmail, so thats not huge problem for me.
Everyone else seems content with a snappy web interface.

 -Enda.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

Re: Sqwebmail bug?

by Enda Cronnolly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Roger B.A. Klorese wrote:
> But that's not what those words mean to the likely naive user. "Disconnect
> other sessions for this user, if active" means what you intend.  "Restrict
> access" seems to mean not to allow access to another IP address AFTER THIS
> LOGIN.

Yeah, its kinda a moot security feature, you're not restricting anything
except multiple concurrent web accesses to a Maildir. Its probably a feature
I will hide from the login gui going forward, I don't see huge value in it
other than it being a flag to alert a user thats something up, ie, if you
have to keep re-logging in, then an admin should be able to tell you thats
probably beause someone else is accesing your account through the web
interface. The same credentials could just give them undetected imap access
to your account anyway, so the point is somewhat lost.

 -Enda.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

Re: Sqwebmail changes - was Re: Sqwebmail bug?

by Sam Varshavchik :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Enda writes:

> The strategy I was going for was to databse index the textual content of a
> Maildir, and to use a FAM based agent to keep the index current. That has
> inherent complexities too for content deletions which I'm working around in
> my head,

You should develop this is a separate utility or tool, with a library API.
This will be of benefit not just to sqwebmail.

Not all platforms have FAM or Gamin. You can't make that a requirement if
this code was part of sqwebmail.




-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail

attachment0 (204 bytes) Download Attachment

Re: Sqwebmail changes - was Re: Sqwebmail bug?

by Enda Cronnolly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sam wrote:

> Enda writes:
>
>> The strategy I was going for was to databse index the textual content of
>> a
>> Maildir, and to use a FAM based agent to keep the index current. That has
>> inherent complexities too for content deletions which I'm working around
>> in
>> my head,
>
> You should develop this is a separate utility or tool, with a library API.
> This will be of benefit not just to sqwebmail.
>
> Not all platforms have FAM or Gamin. You can't make that a requirement if
> this code was part of sqwebmail.

Ah... thanks for the heads up on that.

Regards,

 -Enda.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Courier-sqwebmail mailing list
Courier-sqwebmail@...
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-sqwebmail