Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login credentials lost when opening a new window (tabopen) #154

Closed
isene opened this issue Dec 10, 2014 · 32 comments
Closed

Login credentials lost when opening a new window (tabopen) #154

isene opened this issue Dec 10, 2014 · 32 comments
Labels

Comments

@isene
Copy link

isene commented Dec 10, 2014

I am logged in to e.g. eBay and follow a link with middle-click to open the link in a new window/tab (window manager = i3). New window/tab opens but I have to log in to eBay again.

@fanglingsu
Copy link
Owner

Ok, I can confirm this. Also on github the session is not available if a new instance is spawned.
What are your settings for cookie-accept, cookie-expire-time and cookie-timeout? Can you check if the eBay cookie is written to $XDG_CONFIG_HOME/vimb/cookies?

With following option the session is also available if a new instance is opened.

  • cookie-accept=always
  • cookie-expire-time=-1
  • cookie-timeout=4800

Following works for me vimb -C 'set cookie-accept=always' -C 'set cookie-expire-time=-1' -C 'autocmd!' -C 'set scripts=on' ebay.de

@fanglingsu
Copy link
Owner

I've normally JavaScript disabled, so when I open a link into a new window this has no JavaScript and does not use the session. If I :set scripts=on in config file or by :autocmd than I'm logged in also when opening link into new window. I think that this issues is somewhat related to JavaScript.

@isene
Copy link
Author

isene commented Dec 11, 2014

Thanks. Working now with the tips you have given.
Would be nce to have this as parts of the doc somewhere.

@fanglingsu
Copy link
Owner

What made the difference? Did the scripts fixed this for you too? I'm not sure if this is worth for documentation, it seems to be a general issue of some pages that heavily depend on JavaScript and not an issue of vimb or webkit.

@isene
Copy link
Author

isene commented Dec 12, 2014

Yep, that fixed it :-)

I did spend some time fiddling around to find the solution, so a mention in a FAQ or such would be nice.

Case closed.

@fanglingsu
Copy link
Owner

As you where confrontated with the issue and solved it, I'll ask you to write a little section for the FAQ-Page. You can post it here and I'll publish it.

@isene
Copy link
Author

isene commented Dec 18, 2014

Yes, I could do that (I like the way you inspire cooperation here).

But - the issue has returned... It seems the session times out much earlier than dwb, luakit or uzbl (all tabbed) and that the only session that in fact doesn't time out is facebook (the others that time out during a day is: ebay, wordpress, HP forum, LinkedIn, GitHub and Google).

@fanglingsu
Copy link
Owner

I think you should set cookie-timeout in vimb to a higher value. This timeout is applied if the server wants to set a session cookie (no lifetime set). Such cookies are stores only somewhere in libsoup or webkit and are not written to cookies file. But vimb requires them to be in cookie file so that new vimb instances can pick up the session too.

@isene
Copy link
Author

isene commented Dec 21, 2014

I set it to 48000, but the issue remains (except LinkedIn which is now fine like Facebook). There is no such issue with dwb or luakit or uzbl-tabbed. If the issue cannot be fixed, it makes it even more importnt to have the formfiller for vimb...

@fanglingsu
Copy link
Owner

I'm a little confused. There are two issues we discussed about.

  1. Session is lost in case you open a link into new window (ebay).
  2. Session times out to early, or earlier than expected.

The first issues is fixed for you, by some change you applied to your config file. Right? On which pages can I check the second issue? And what means that it still exists? When is the session lost?

@kirelagin
Copy link

Let me jump into this issue too.
I think what I see is those early timeouts.
This happens randomly with Google (e.g. the session wasn’t lost when I opened Gmail this morning) but I had to relogin once yesterday during the day. Almost definitely this happens to VK (Russian social network) and Twitter. GitHub is ok.

It’s really hard to tell what is going on and when. I’ll try to keep records (just logged into Twitter).

@kirelagin
Copy link

By the way, are you saying that this might have something to do with session cookies? I could neither figure out what does cookie-timeout do, nor understand the format of cookies. What should I be looking for there?

@kirelagin
Copy link

Before logging into Twitter I had guest_id, _ga, _gat and this weird #HttpOnly_.twitter.com with _twitter_sess set. Now, after logging in again, lang, twid, remember_checked_on and two new #HttpOnly_.twitter.com (auth_token and kdt) appeared.

@fanglingsu
Copy link
Owner

I could neither figure out what does cookie-timeout do, nor understand the format of cookies.

The cookie-timeout is the lifetime of a set cookie in seconds in case the server set the cookie with expire time of 0 (until the browser session is aborted or the browser is closed). The cookies with expire time of 0 would normally handled as session cookies in webkit - means they would not be written to the sesstion storage ($XDG_CONFIG_HOME/vimb/cookeis) and only kept in memory. This is a good decision the webkit developers made, but it's not good for vimb. Vimb uses a new browser instance for each openend window (at least at the time - this will be changed a little if we port vimb to webkit2). So we could not access cookies set in one instance/window from within another window. that means if you are logged in in an application and open a link into a new window, you would not be logged in the new window.
So we changed the way the cookies with expire time of 0 are stored, by setting a default expire time of cookie-timeout to force webkit to store them in the cookies file so we can pick them up in other instances or for the external download command.

The explanation to the cookies file formant can be found at : http://www.cookiecentral.com/faq/#3.5
The #HttpOnly_ before the cookies domain indicates http only cookies - these are normals cookies, but these will never be accessible in the dom of the page (can't be read by JavaScript for example).

@shioyama
Copy link
Contributor

Hmmm... anybody make any progress on this issue, or come up with a workaround? I'm liking vimb a lot but this issue is a killer if you're using 2-factor auth, for google I need to keep re-entering verification codes randomly if I open a google page in a new tab (window). Glad to see it's not just me but would be great to find a solution...

@fanglingsu
Copy link
Owner

In case of google it should be enough to set cookie-accept=always. not that this have to be set for the new window too on startup. To test you can run vimb -C 'set cookie-accept=always' from CLI, authenticate on google and open a new window from there.

Are you not logged in in a new openend window or does the session expire to fast?

@fanglingsu
Copy link
Owner

@shioyama Have you tried to set cookie-expire-time=... to something greater as 0? This would overwrite cookie timeout sent by the server. This will also set a timeout on cookies set without such (session cookies) and will force vimb to store them in the cookie file. normally session cookies (without timeout) are not stored in the cookie file and are therefore not accessable by new vimb instances.

@shioyama
Copy link
Contributor

@fanglingsu I now have:

set cookie-accept=always
set cookie-expire-time=-1
set cookie-timeout=48000

And I still find that this happens, although I can't pinpoint the cause. Github seems to work ok, but on some other sites I also have to login again. Google is the biggest pain because I have to re-enter a validation code.

Just now I restarted my laptop with those settings so I should have an existing cookie and not have to login, but again I'm redirected to the login page. Not quite sure what's going on, I'll try to dig into what's actually happening in the cookies file.

@shioyama
Copy link
Contributor

Just to check, if I have cookie-accept=always in my config I shouldn't have to pass it when running it from the command line, right? I'm sure that it's reading the config since other config settings are set correctly.

@shioyama
Copy link
Contributor

So for example, right now I have two windows open side-by-side, one logged-in to gmail and one which is redirecting me to the gmail sign-in. I can check in the new window and see that the config settings are there and set correctly.

I've tried various different things but always I'm redirected to login, while the other window remains logged in (even if I reload it).

One thing I do notice is that my cookies file is very short, which is not what I would expect if I'm telling vimb to keep all my cookies for a very long time. I do see google cookies in there, not sure if they are enough... will have to investigate further.

@fanglingsu
Copy link
Owner

@shioyama Did you check with set cookie-expire-time=4800?

But google bahves a litte strange I think. I've logged in to google and started another vimb instance from cli to google and was logged in there. After logout on the second instance I still kept logged in in the first instance.
Maybe the issue is related to the way webkit read in the cookie file, maybe this is not read again after it was changed by another running vimb instance.

@shioyama
Copy link
Contributor

It's strange because it seems that sometimes it works, other times it does not. Right now I am able to open tabs and login persists, but earlier today it was not working. It seems like something triggers vimb to stop reading the cookie from the file (or maybe the cookie is removed, not sure yet because hard to see exactly which one is which).

@shioyama Did you check with set cookie-expire-time=4800?

I checked with that and then with 48000. Is there any reason a smaller value would work whereas a larger one would not? I just figured set it as high as possible.

@shioyama
Copy link
Contributor

Ok sorry, I was getting cookie-expire-time and cookie-timeout mixed up. I'm still not sure if it is working but I'm testing with cookie-expire-time=4800 now.

Ah but now I'm finding that it's logging me out really fast...

@shioyama
Copy link
Contributor

Ok it seems the combination of cookie-timeout and cookie-expire-time were perhaps the issue. I've removed cookie-timeout and it seems (fingers crossed) to be using the cookies across windows without issues. I'll report back if I have more issues. Thanks for the help!

@fanglingsu
Copy link
Owner

Oh, interesting, In my opinion the cookie-timeout should not cause such an behaviour. Did you set it to 0?

@shioyama
Copy link
Contributor

shioyama commented Aug 1, 2015

No I set it to a positive value, but I found that it would suddenly expire. I've now set it to a very very high value and testing with that, because not setting it at all allowed cookies to expire after a while.

At this point I'm really not sure what is causing what. Is there any chance that time may be calculated incorrectly? Maybe time-zone related? Just grasping for straws here.

@fanglingsu
Copy link
Owner

If you don't set any cookie-timeout the internal default of 4800 will be used (1h). I think it's best to set cookie-tiemout and cookie-expire-time to the same value in this case.

@shioyama
Copy link
Contributor

shioyama commented Aug 6, 2015

Thanks, this seems to be working now. Although I'm not so happy to be storing all my cookies for such a long time, I'm just happy that I don't need to keep re-entering two-factor auth codes all the time. Would be great to implement webkit2 if that would allow a more natural way to do this.

The upside to all this is that I got around to actually digging into the vimb code a bit and would like to help contribute if I can, there are still a couple other bugs like #214 that driving me a bit nuts.

Thanks for all your help!

@shioyama
Copy link
Contributor

shioyama commented Aug 6, 2015

Ah, you know this is still not working. Something is re-setting my cookies, not really sure what it could be but it seems to affect more than just gmail/google. I'll try to pinpoint the issue but would be eager to hear if anyone else is experiencing this... perhaps related to my config or something.

@fanglingsu
Copy link
Owner

Maybe google is resetting some of the cookies because something seems to look like an hacking attempt, because the user agent for the same session is considered to be wrong. Oh, that is only an uneducated guess.

@shioyama
Copy link
Contributor

shioyama commented Aug 7, 2015

No it's not just google but seemingly all cookies. I've found an ugly workaround now where I just save my cookies when I login, then if they get reset I just copy back the previous cookie file, that seems to work. But I still can't pinpoint what is causing them to get reset in the first place. Maybe something to do with multiple processes trying to edit the cookies file at once? No idea. Maybe specific to my setup.

@fanglingsu
Copy link
Owner

Closed this because this is now continued in #235.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants