[Edbrowse-dev] Accessing fastmail

[Edbrowse-dev] Accessing fastmail

[Chuck Hallenbeck]

-- 
Everyone says nothing rhymes with purple but I don't think it does
Hi all,

Well, it turns out I am able to log into my fastmail account after all,
using the address classic.fastmail.com, but only if JS is disabled.
Once logged in, I can take some actions, but not others.  For instance I
can mark an email for the purpose of deleting it, but then pressing the
delete button results in the following error message, with or without
JS enabled:

Internal error

There was a session security key mismatch.  This is most likely because
your session expired and you logged back in on a different tab or window
of your browser.  Please close this tab or window and try again.


Also, using the classic.fastmail.com address, elinks now works as expected
on fastmail.  If you are not familiar with it, elinks is a full screen
text mode browser with javascript support.
 ..
I appreciate your giving fastmail your priority, but like Karl I have
no screen display to worry about. I like the idea of a pw command
for passwrd fields, but it must not only mask the screen output, but
suppress the key-by-key typing of the password prior to pressing enter
to be totally secure.

Chuck -

Re: [Edbrowse-dev] Accessing fastmail

[Chris Brannon]

Chuck,
Does fastmail offer free accounts, or are they all paid?

-- Chris

[Edbrowse-dev] Accessing fastmail

[Karl Dahlke]

Chuck, this sort of error

> There was a session security key mismatch.

is almost certainly a cookie problem.
Websites set cookies that "remember" the session
and if the cookie is not returned in kind the server invalidates the session.
This goes back to another email posted, wherein the login button
has an onsubmit function that sets the cookie,
probably the session cookie described above.
So I imagine this session cookie is not set properly in js,
back to edbrowse, and into curl, or some such.
The cookie code posted seems incompatible with
what the document.cookie settter function expects.

use_classic=1;max-age=604800;expires=Fri, 25 Dec 2015 01:52:50GMT;path=/

All run together no spaces.
However, look through the foldinCookie() function in jseng-moz.cpp.
I think it expects spaces after the semis though that isn't the problem,
it definitely expects a tab between the cookie itself
and the expires path attributes.
In other words, I'm not sure this is netscape cookie format.

1. What can really be fed to document.cookie in js.

2. Did you post this per characters, is this really the string
that foldinCookie has to swallow?

3. If yes then how does it magically know what are cookies
and what are cookie attributes, without the tab?

Again I don't have a login here, but Maybe Kevin and Chuck can answer some of these,
and Chris as our resident cookie expert.

Again, if we fix this problem for this site a lot of other sites
will start working; the session cookie is a very
common strategy on the internet.

Karl Dahlke

Re: [Edbrowse-dev] Accessing fastmail

[Kevin Carhart]

This is interesting.. yes, so we just
fixed the problem with the onsubmit, meaning
(thinking out loud)
that in spite of the fact that the onsubmit
doesn't have a return value, the appropriate
routine in ebjs (run_function_bool) now
defaults to true rather
than defaulting to false if it bails out
early.  So we did that even though Karl said
"this could have ramifications beyond just
this one scenario."  I guess maybe it's a
rare case that if it's a function that is
supposed to return true or false, that they
would just leave it off and not return anything.

So that's the background.
  Hopefully it's pretty
rare and/or this is actually the right thing
to do broadly.

> So I imagine this session cookie is not set properly in js,
> back to edbrowse, and into curl, or some such.
> The cookie code posted seems incompatible with
> what the document.cookie settter function expects.
>
> use_classic=1;max-age=604800;expires=Fri, 25 Dec 2015 01:52:50GMT;path=/
>
> All run together no spaces.

Indeed - when I play along, try to delete an email
and I get the same session error that Chuck gets, I then
examined document.cookie using jdb:
jdb
document.cookie
use_classic=1

So that's confirmation that the cookie is being truncated.
(I'm happy about jdb mode!  It's helpful for getting a
quick answer inline.)

Knowing this, what do we do?

Kevin