gerrithub.io seems not to remember my login quite often, amnesia?

[Sorin Ionuț Sbârnea]

Hi! it seems that I get logged of gerrithub.io quite often (probably daily). Any idea on who can fix this? I do not remember when it was the last time when I had to re-login to github or to google, they seem to be able to remember my login for a long enough period of time.

I don't know if this is linked to server restarts, upgrades or just sessions expiring but I think that any web application should be able to remember logins for at least 72 hours (so you would not have to login on a Monday morning).

Am I the only one that encounters these? Maybe is related to VPN usage? Can we feed gerrithub some more lecithin maybe? :D

Cheers

Sorin

[Luca Milanesio]

Hi Sorin,

Gerrit's default session expiry time is actually 12 hours (see https://gerrit-review.googlesource.com/Documentation/config-gerrit.html)

This means that sessions that are inactive for 12 hours or more will be removed and you'll need to login again.

However, the login process involves only pressing the "Login" button because it is done using OAuth with GitHub which as its cookie associated.

Bottom line: you should be asked by GitHub to login again ... press the "Login" button and it should work without asking for credentials.

What is your current user-experience? Does GitHub ask you for username/password all the times?

Nobody has ever requested to have longer session timeouts, however, it can be simply changed to 24h.

I wouldn't consider "safe" to have sessions that last for multiple days, weeks or months though.

HTH

Luca.

Cheers

Sorin

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

Hi Sorin,

it seems that the current timeout is 2 days (48h): this means that as soon as you use Gerrit at least "once every 2 days" you won't be asked to push that button.

Pushing a login button once every 2 days (let's say 100 times a year), which takes around 2-3 secs would mean spending 300 secs a year for login (5 mins).

Isn't that acceptable for you?

On 24 Jan 2017, at 11:24, Sorin Ionuț Sbârnea <sorin....@gmail.com> wrote:

Thanks for the update, I think that an extension to 24 hours would be great. I don't mind pushing that login button once a week. --- Once a day was annoying.

Not sure how many sessions are expired per day but here is an estimation regarding possible time saves:

5000 * 5 seconds  = ~ 7h ... saving almost a full time developer :)

There are currently 260 non-expired sessions on the system, and they are up to 2 days old.

Are you sure you're getting logged out every day? Can you point to a couple of time-stamps?

Luca.

Gerrit's default session expiry time is actually 12 hours (see https://gerrit-review.googlesource.com/Documentation/config-gerrit.html)

Nope, I don't have session expiration problems with other systems.

Thanks

Sorin

[Saša Živkov]

On Tue, Jan 24, 2017 at 12:27 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi Sorin,

it seems that the current timeout is 2 days (48h): this means that as soon as you use Gerrit at least "once every 2 days" you won't be asked to push that button.

Pushing a login button once every 2 days (let's say 100 times a year), which takes around 2-3 secs would mean spending 300 secs a year for login (5 mins).

Isn't that acceptable for you?

On 24 Jan 2017, at 11:24, Sorin Ionuț Sbârnea <sorin....@gmail.com> wrote:

Thanks for the update, I think that an extension to 24 hours would be great. I don't mind pushing that login button once a week. --- Once a day was annoying.

Not sure how many sessions are expired per day but here is an estimation regarding possible time saves:

5000 * 5 seconds  = ~ 7h ... saving almost a full time developer :)

There are currently 260 non-expired sessions on the system, and they are up to 2 days old.

Are you sure you're getting logged out every day?

Unrelated to gerrithub.io, some of our users also complained being logged out several times per day from our internal Gerrit server.

Even with web_sessions cache large enough to not cause removing LRU entries and the session timeout set to much longer than

1 day, this still happens for some users sporadically.

I couldn't yet find a root cause of this issue.

 

Can you point to a couple of time-stamps?

Luca.

Gerrit's default session expiry time is actually 12 hours (see https://gerrit-review.googlesource.com/Documentation/config-gerrit.html)

Nope, I don't have session expiration problems with other systems.

Thanks

Sorin

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Luca Milanesio]

Hi Saša,

thanks for the feedback: it could well be that Sorin is experiencing the same issue with GerritHub.io :-(

Luca.

[David Ignjić]

We have same problem we set up web expiration time to 1 year and still after 1 to 2 days (or change network) I am logout. 

What could be cause we every day in midnight make backup of gerrit database so we make restart with gerrit script (and that probably mess up)

I will try change backup strategy.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Saša Živkov]

On Thu, Jan 26, 2017 at 4:20 PM, David Ignjić <ign...@gmail.com> wrote:

We have same problem we set up web expiration time to 1 year and still after 1 to 2 days (or change network) I am logout. 

What could be cause we every day in midnight make backup of gerrit database so we make restart with gerrit script (and that probably mess up)

The sessions are stored in the web_sessions cache, which is a persistent cache stored in the $GERRIT_SITE/cache/web_sessions.h2.db.

Persistent caches survive Gerrit server restart. I don't think that your backup is related to this issue...

Have you configured the web_sessions cache large enough to store sessions of all of your Gerrit users?

We definitely see this issue without restarting Gerrit.

[David Ignjić]

Which configuraiton parameters is it ?

you mean memoryLimit ? 

[David Shrum]

We have also investigated this with our internal Gerrit where users usually have to login again every couple of days even though our expiration time is set to 7 days.  We also made sure to increase the cache size to hold all users and monitored that it was not the problem.  In the end, we couldn't find a solution, so would be interested if this is solved.

[Saša Živkov]

I investigated this issue further. What is interesting is that when happens I see an entry in the httpd_log

with 403 (Forbidden) but *including* username:

10.18.197.28 - johndoe [02/Mar/2017:12:13:25 +0100] "PUT /changes/522723/revisions/83e8e014238094d32e98f12cc65e575462bbd41e/drafts HTTP/1.1" 403 129 "https://hdbgerrit.wdf.sap.corp:8443/" "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

The only circumstances under which the username will be available when this issue happens are:

* user has a valid session

* the GerritAccount cookie is included in the request

* the X-Gerrit-Auth is *not* included in the request

In any other case like user's session expired or GerritAccount cookie not sent, the username would not be included in the httpd_log.

Therefore, my current assumption is that this issue happens when browser doesn't include the X-Gerrit-Auth header.

This might be a bug in some versions of some browsers or a bug in Gerrit UI code.

It is interesting that this issue hits some users often and other users seldom or never.

Those who can reproduce the issue: it would help if you open the developer tools (Chrome) or the equivalent in Firefox

and keep it open until the issue happens. Then find the last request with the 403 response code, look at the request headers

and let me know which headers are (not) included.

[Luca Milanesio]

Hi Saša,

thanks for sharing your analysis.

Let me dig into our logs if we see something similar ...

Luca.

[Luca Milanesio]

Bingo: we see the same problem.

# grep ' 403 ' httpd_log* | grep -v ' - - ' | wc -l
11

It is quite sporadic though, only 11 entries over 49K calls (0.02%) but it is an issue for sure.

I thought that the X-Gerrit-Auth was a thing of the past ... but we still use in the GWT UX isn't it?

If I am not mistaken, one is stored as a cookie (GerritAccount) whilst X-Gerrit-Auth is archived in the user session server-side and returned in the first GWT screen loaded, isn't it?

Luca.

[Saša Živkov]

On Fri, Mar 3, 2017 at 5:14 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Bingo: we see the same problem.

# grep ' 403 ' httpd_log* | grep -v ' - - ' | wc -l
11

It is quite sporadic though, only 11 entries over 49K calls (0.02%) but it is an issue for sure.

I thought that the X-Gerrit-Auth was a thing of the past ... but we still use in the GWT UX isn't it?

GWT UI uses it. 

If I am not mistaken, one is stored as a cookie (GerritAccount) whilst X-Gerrit-Auth is archived in the user session server-side and returned in the first GWT screen loaded, isn't it?

 

Yes, the HostPage will communicate it back to the client as XSRF_TOKEN cookie.

After that the client is supposed to send it as X-Gerrit-Auth header in each request for this session.

Server-side session stores the expected X-Gerrit-Auth value. If it is not included or included but invalid

then the REST_API access path is forbidden for this request.

 

Luca.

To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Luca Milanesio]

The list of browsers user-agent that had this problem in the 11 calls mentioned are:

      1 Mozilla/5.0 (Linux; Android 6.0.1; P01MA Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
      1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
      1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
      1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
      1 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
      1 Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
      1 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36
      2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:51.0) Gecko/20100101 Firefox/51.0
      3 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Chrome, Firefox, Mac, Windows, Linux ... don't think it is browser or OS-specific then :-(

Must a bug somewhere in our code ...

Luca.

[ssba...@redhat.com]

Do we have any updates on this? It seems that the experience persists: I am forced to login again at least once a day if not even more, and I visit Gerrit a LOT.

[Sebastian Schuberth]

On Tuesday, July 18, 2017 at 10:30:40 AM UTC+2, ssba...@redhat.com wrote:

Do we have any updates on this? It seems that the experience persists: I am forced to login again at least once a day if not even more, and I visit Gerrit a LOT.

Also, is this tracked as an issue yet? Now that it seems to be confirmed to be an issue in Gerrit we should probably do so.

Regards,
Sebastian

[lucamilanesio]

Yes, there is now an official issue on this problem:

https://bugs.chromium.org/p/gerrit/issues/detail?id=8347

It seems that even if the session is in cache, not expired, still valid ... the GerritAccount Cookie Expiry date doesn't get updated and thus the user is not able to recover it anymore :-(

Genuine issue to be resolved IMHO.

Luca.

[Saša Živkov]

On Fri, Feb 9, 2018 at 12:11 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

Yes, there is now an official issue on this problem:

https://bugs.chromium.org/p/gerrit/issues/detail?id=8347

It seems that even if the session is in cache

How do you know if it is in the (web-sessions) cache?

 

, not expired, still valid ... the GerritAccount Cookie Expiry date doesn't get updated and thus the user is not able to recover it anymore :-(

Genuine issue to be resolved IMHO.

Another possibility is that you have an user who (programmatically) creates a large number of sessions without logging them out.

As the number of sessions approaches the max size of the web_sessions cache, guava cache will start to remove entries

from the cache and people will start loosing their sessions.

 

Luca.

On Thursday, July 27, 2017 at 9:02:09 PM UTC+1, Sebastian Schuberth wrote:

On Tuesday, July 18, 2017 at 10:30:40 AM UTC+2, ssba...@redhat.com wrote:

Do we have any updates on this? It seems that the experience persists: I am forced to login again at least once a day if not even more, and I visit Gerrit a LOT.

Also, is this tracked as an issue yet? Now that it seems to be confirmed to be an issue in Gerrit we should probably do so.

Regards,
Sebastian

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Sebastian Schuberth]

On Fri, Feb 9, 2018 at 3:27 PM, Saša Živkov <ziv...@gmail.com> wrote:

> Another possibility is that you have an user who (programmatically) creates
> a large number of sessions without logging them out.
> As the number of sessions approaches the max size of the web_sessions cache,
> guava cache will start to remove entries
> from the cache and people will start loosing their sessions.

Could this also happen if not a single user creates many sessions, but
many users create one session each without logging out?

--
Sebastian Schuberth

[Saša Živkov]

Yes. The main point is that the total number of sessions approaches the max size

of the web_sessions cache. When this happens guava starts evicting entries from

the cache, and each evicted entry means an invalidated session.

I mentioned the example with one user creating many sessions (programmatically)

as a more likely case because I had several such incidents on our production servers.

 

--
Sebastian Schuberth

[Luca Milanesio]

On 9 Feb 2018, at 14:27, Saša Živkov <ziv...@gmail.com> wrote:

On Fri, Feb 9, 2018 at 12:11 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

Yes, there is now an official issue on this problem:

https://bugs.chromium.org/p/gerrit/issues/detail?id=8347

It seems that even if the session is in cache

How do you know if it is in the (web-sessions) cache?

I just started the server, I did a show-caches, just one entry of 1024, 7 days TTL :-)

 

, not expired, still valid ... the GerritAccount Cookie Expiry date doesn't get updated and thus the user is not able to recover it anymore :-(

Genuine issue to be resolved IMHO.

Another possibility is that you have an user who (programmatically) creates a large number of sessions without logging them out.

As the number of sessions approaches the max size of the web_sessions cache, guava cache will start to remove entries

from the cache and people will start loosing their sessions.

That wasn't the case, this was reproduced in a single test environment.

I definitely believe it is a genuine issue.

[Saša Živkov]

On Fri, Feb 9, 2018 at 3:42 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

On 9 Feb 2018, at 14:27, Saša Živkov <ziv...@gmail.com> wrote:

On Fri, Feb 9, 2018 at 12:11 PM, lucamilanesio <luca.mi...@gmail.com> wrote:

Yes, there is now an official issue on this problem:

https://bugs.chromium.org/p/gerrit/issues/detail?id=8347

It seems that even if the session is in cache

How do you know if it is in the (web-sessions) cache?

I just started the server, I did a show-caches, just one entry of 1024, 7 days TTL :-)

 

, not expired, still valid ... the GerritAccount Cookie Expiry date doesn't get updated and thus the user is not able to recover it anymore :-(

Genuine issue to be resolved IMHO.

Another possibility is that you have an user who (programmatically) creates a large number of sessions without logging them out.

As the number of sessions approaches the max size of the web_sessions cache, guava cache will start to remove entries

from the cache and people will start loosing their sessions.

That wasn't the case, this was reproduced in a single test environment.

I definitely believe it is a genuine issue.

Interesting.

Also interesting that not everyone sees this issue.

I am curios about findings from your test environment.

[Luca Milanesio]

The problem can be easily reproduced using the DockerHub images of gerrit using a Ver. 2.14.6:

https://gerrit.googlesource.com/docker-gerrit

1. Start a Docker-compose setup as described in the "Using Gerrit in production" section

https://gerrit.googlesource.com/docker-gerrit#using-gerrit-in-production

2. Login and select "remember me"

3. The GerritAccount cookie is set with 12h expiry

1. Request URL:
   http://localhost/login/%23%2Fq%2Fstatus%3Aopen
2. Request Method:
   POST
3. Status Code:
   302 Found
4. Remote Address:
   127.0.0.1:80
5. Referrer Policy:
   no-referrer-when-downgrade

1. Cache-Control:
   no-cache, no-store, max-age=0, must-revalidate
2. Content-Length:
   0
3. Date:
   Fri, 09 Feb 2018 15:10:24 GMT
4. Expires:
   Thu, 01 Jan 1970 00:00:00 GMT
5. Location:
   http://localhost/#/q/status:open
6. Pragma:
   no-cache
7. Set-Cookie:
   GerritAccount=aSceprr3NaUvgROZCWa5FyYGbCfIIxlU0W;Path=/;Expires=Sat, 10-Feb-2018 03:10:24 GMT

As a user I would expect to be logged out after 12 hours of inactivity and the Cookie automatically extended.

This happens in fact at websessions level on the backend cache: as long as the session gets referenced I would expect to be valid if we are not going over the Guava cache limit (1024).

Instead what I see if I refresh the page:

1. Accept:
   text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
2. Accept-Encoding:
   gzip, deflate, br
3. Accept-Language:
   en-GB,en;q=0.9,en-US;q=0.8,it;q=0.7
4. Cache-Control:
   no-cache
5. Connection:
   keep-alive
6. Cookie:
   GerritAccount=aSceprr3NaUvgROZCWa5FyYGbCfIIxlU0W; XSRF_TOKEN=aSceprtxaN80WdXZphje4.GH9LDIBZ-JiG
7. Host:
   localhost
8. Pragma:
   no-cache
9. Referer:
   http://localhost/login/%23%2Fq%2Fstatus%3Aopen
10. Upgrade-Insecure-Requests:
    1
11. User-Agent:
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

1. Cache-Control:
   no-cache, no-store, max-age=0, must-revalidate
2. Content-Encoding:
   gzip
3. Content-Length:
   980
4. Content-Type:
   text/html;charset=utf-8
5. Date:
   Fri, 09 Feb 2018 15:13:13 GMT
6. Expires:
   Mon, 01 Jan 1990 00:00:00 GMT
7. Pragma:
   no-cache
8. Set-Cookie:
   XSRF_TOKEN=aSceprtxaN80WdXZphje4.GH9LDIBZ-JiG;Path=/

So basically the GerritAccount cookie is sent in the request but *IS NOT* returned in the response extended in time.

This means that after 12h of *active usage of Gerrit*, the session would expire anyway and I will be forced to login again.

You should be able to reproduce the same situation using the DockerHub image with Gerrit 2.14.6.

Let me check the code on why the GerritAccount cookie is not getting extended ...

Luca.

[Luca Milanesio]

Checked the code.

The problems seems on when the CacheBasedWebSessionManager.saveCookie() gets invoked: only during login/logout.

Basically, when you do anything else, there is no reference to any part of the code of storing the GerritAccount cookie.

That cookie will eventually expire. Even if the websession is effectively still in cache or even persisted on disk, the Browser would have no way to come back to it :-(

Luca.