For Nuance and Maniphest, at a minimum, we want grey users to be able to login and interact with Phabricator over the course of a session, not just a single page. Other types of interactions, like Legalpad verifications, might be better captured with single-page worklfows, but if someone reports an issue on Twitter to Nuance, they should be able to login and interact with that ticket over the course of multiple pages.
Description
Description
Revisions and Commits
Revisions and Commits
| rP Phabricator | |||
| D8043 | rP69ddb0ced631 Issue "anonymous" sessions for logged-out users | ||
| D7978 | rP2ec45d42a689 Remove session limits and sequencing | ||
| D7976 | rPacb141cf52c1 Expire and garbage collect unused sessions | ||
| D7975 | rPa64228b03fbc Give the session table a normal `id` column as a primary key | ||
| D7963 | rPd392a8f15700 Replace "web" and "conduit" magic session strings with constants | ||
| D7962 | rPeef314b70149 Separate session management from PhabricatorUser | ||
| D7954 | rP3d9e328fb388 Add an "active login sessions" table to Settings | ||
| D7953 | rP220d680f3769 Allow PhabricatorUserLog to store non-user PHIDs | ||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Duplicate | None | T4310 Allow external users to establish real sessions | ||
| Resolved | epriestley | T4339 Support CSRF for logged-out users |
Event Timeline
Comment Actions
I poked at this a bit. Here's the stuff I've hit so far:
- The session code lives in $user->establishSession() and is hard-coded to users. This needs to be made more general, so you can login as an arbitrary PHID (in concrete terms, either a user PHID or an external account PHID, but maybe we'll add Pages later or something).
- Sending the external login flow through the AuthLink controller seems to make the most sense. It's the nearest existing workflow. I have a patch to do this, but it dead-ends when it tries to establish a session since it can't session an ExternalAccount right now.
- The grey PhabricatorUser objects generated by ExternalAccount respond to isLoggedIn right now, which they definitely should not. I'm not sure if they should be considered public accounts and then given a few exceptions, or put into some new grey-user class. (Also maybe we should call these something other than "grey" users, although I think the term is relatively unambiguous, while "external user" can mean several things.)
Broadly, I came at this from the angle of getting the login workflow working first, but probably need to get sessions working first instead.
Comment Actions
https://secure.phabricator.com/differential/diff/17974/ is my very rough attack on login workflow.
Comment Actions
Run arc diff --only, or click the ID column in the "Revision Update History" table on a revision.
Comment Actions
We're well positioned to implement this now, but we don't need it quite yet for Nuance, right? I'm inclined to hold off on the actual flow for a bit and let all the changes settle for a few days, at least, if this isn't going to be blocking anything in the immediate future.
Comment Actions
I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella. That is, the future for these use cases mostly looks like "lightweight/external users interact with Nuance, then staff triage issues into other objects like Tasks that only real users interact with", not "lightweight/external users interact with every application and every application gains support for email/external/grey interactions".