| Summary: | Site login requires connection to foundation_ro... why? | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Denis Roy <denis.roy> | ||||
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | webmaster | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Denis Roy
It seems to be part of the friends init sequence. I've moved it into another part of the relevant class which should prevent it from being called during the login process. -M. Reopening. If we are expected to use the committer status on www (for bug 376732) it's better to load up the committer status at login. The Friends object (which contains this status) is serialized to the sessions table on dbmaster/slave. SO I'm effectively undoing this change. I will try to arrange it so that foundation_ro can fail silently, so that user authentication is never blocked by a missing DB server. Created attachment 214112 [details]
Patch
An even better way to do this is to examine the dn after a successful authentication. If you're in ou=people, forcibly you're a committer. No SQL query, no additional LDAP.
# Load up committer status
if(preg_match('/ou=people,/i', $dn)) {
$Friend->setRoles("::CM::");
}
COmmitted. |