| Summary: | [site_login] ends in a login loop, no login possible -- possible issue with VPN and Proxy clients | ||
|---|---|---|---|
| Product: | Community | Reporter: | Thomas Neustupny <thn-d> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | chris.guindon, denis.roy, thn-d, webmaster |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 435405 | ||
|
Description
Thomas Neustupny
I tried again today, and the problem was gone. So what happened? I got news on this: today I figured that the problem occurs when a VPN (Check Point VPN) is running on my Win XP machine, and a connection is established. I verified that closing the connection gets rid of the problem. Hope this info is useful. For me it's solved. Which one is the appropriate status now? Thomas, this is great info; thanks for the follow-up. For some reason, certain proxy (and now VPN) environments seem to cause issues with our login. The proxy issue was known; that VPNs can cause this is news to me, but knowing this will likely help others figure out the problem. I'll leave this open for investigation, but reduce the severity. Thanks again for the great report. I found a bug... which may be responsible for what we've been seeing here. in session.class.php, when we load a session, we call maintenance(). That maintenance function is used to delete stale sessions. The query, however, does much more: 1. DELETE FROM sessions 2. WHERE (updated_at < DATE_SUB(NOW(), INTERVAL 7 DAY) AND is_persistent = 0) 3. OR (subnet = '" . $this->getClientSubnet() . "' AND gid <> '" . $App->sqlSanitize($this->getGID(), null) . "') 4. OR updated_at < DATE_SUB(NOW(), INTERVAL 1 YEAR) Line 3 essentially deletes all sessions from the same subnet as you're on... except your own. Proposed change does two things: 1. Removes line "3" from the above query 2. Touches the "updated at" time, which was the intention of the field in the first place. https://git.eclipse.org/r/28378 Once this change has been in production for a while, we'll be able to trim sessions based on the (more accurate) updated_at field. Thomas if you're still capable of doing so, would it be possible to test the change? It was deployed late last week. Can we close this bug? I think so. |