Repository navigation
POC A: return to the huddl you came from after signing in - #672
Closed
MichaelDimmitt wants to merge 6 commits into
Closed
MichaelDimmitt wants to merge 6 commits into
MichaelDimmitt wants to merge 6 commits into
Conversation
Issue huddlz-hq#670 asks for several competing proofs of concept, each as its own draft PR, so one can be chosen and the rest declined. This is the shared brief those PRs are built from: the problem, what the code already does, one section per variant with its own task list, and the rubric they are all judged against. Records three findings that shape the variants: the return_to plumbing is already complete and safe but only the huddl page's RSVP button produces such a link; the agenda already loads both scopes every render to feed its chip counts; and the agenda has no query for huddlz outside a person's groups. Part of huddlz-hq#670
The POC variants are compared partly on whether people want to use them, so a variant that looks unfinished loses Desirable and Delightful for reasons unrelated to its idea. Ask each one to polish the surface it changes, and keep the scope discipline pointed at everything else. Part of huddlz-hq#670
3 of 8 tasks
MichaelDimmitt
force-pushed
the
poc/670-return-to-origin
branch
from
October 9, 2026 00:38
e5e25e4 to
443cffa
Compare
A person who arrives on a huddl page from a link or a QR code and reaches for the header's "Sign in" loses the huddl they came for: the header's link is a bare /sign-in, so they land on the agenda, which by definition does not list a huddl they have not RSVP'd to yet. These scenarios describe the journey the person expects. Four of the five fail: signing in or signing up from the header does not come back. The fifth passes already and is meant to — it documents that AuthReturnTo.validate/1 refuses an off-site return destination before any of this work. - Cover sign-in from a huddl page and from a group page - Cover sign-up, where email confirmation intervenes - Cover a tagged arrival, so join attribution survives the sign-in hop Part of huddlz-hq#670
The return_to plumbing was already complete and already safe. What it was missing was reach: only the huddl page's RSVP call to action and the group page's join button produced a return destination. The topbar's "Sign in" and "Sign up" — the buttons that look like the way to sign in — were bare paths, so the two sign-in links on the same page disagreed about whether the person's intent was worth keeping. Layouts.app now takes a return_to a page can fill in, and the topbar's sign-in and sign-up carry it. Validation happens inside the component rather than at the call sites, so no page can hand the header an off-site destination and any future caller is covered without having to remember. The huddl page and the group page pass the destination they already computed for their own buttons, so the header and the in-page call to action cannot drift apart. On the group page that address still carries the join source tag, so attribution survives the trip through auth. - Add a validated return_to attr to Layouts.app - Point the topbar's sign-in and sign-up at it - Pass each page's existing return destination from huddl and group show - Record the measured click count and entry point audit in the POC spec Part of huddlz-hq#670
The POC A Findings block was written with an unbounded string replace, so it landed in all seven variants' sections and overwrote B through G's empty placeholders. The doc then asserted A's click counts and terminology choice as if they belonged to every variant, and would have conflicted with five agents editing those same sections. Rebuilt from the pristine doc: only variant A's section carries Findings, and B through G have their placeholders back byte-for-byte. Part of huddlz-hq#670
MichaelDimmitt
force-pushed
the
poc/670-return-to-origin
branch
from
October 9, 2026 03:42
443cffa to
6314591
Compare
MichaelDimmitt
marked this pull request as ready for review
October 10, 2026 01:44
Contributor
|
Thanks for catching the header sign-in issue, Michael. Returning people to the huddl or group they came from is the right fix. Closing this POC while we prepare a focused replacement that covers the sign-in return paths and preserves the page state through authentication. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
POC variant A — "Return to origin" for #670. Baseline variant: the one the other
five are measured against.
Summary
The
return_toplumbing was already complete and already safe. It was unevenlyapplied — two sign-in links on the same huddl page disagreed about whether the
person's intent was worth keeping:
huddl page, signed out <Layouts.app> topbar - "Sign in" -> /sign-in - "Sign up" -> /register + "Sign in" -> /sign-in?return_to=/groups/:slug/huddlz/:id + "Sign up" -> /register?return_to=/groups/:slug/huddlz/:id "Sign in to RSVP" -> /sign-in?return_to=/groups/:slug/huddlz/:id (already)The person's journey, before and after:
return_tois validated insideLayouts.apprather than at the call sites, so a pagecannot hand the header an off-site destination and any future caller is covered without
having to remember. The huddl and group pages pass the return destination they already
computed for their own buttons, so the header and the in-page call to action cannot drift
apart — on the group page that address still carries the join source tag, so attribution
survives the trip through auth.
Evidence
Screenshot
Debug overlay (not part of the change):
signed out on a huddl page, the overlay prints the real
hrefof the two header links. Both now carry the return destination, which is the whole of this change and the one thing a screenshot of the chrome cannot otherwise show.Actual page:
No visual difference from before. Only the header links' destinations change, which is not shown in the screenshot.
Before —
mix test test/features_test.exs --only header_return_to. The failing testoutput is itself the finding; both links appear in the same page:
Naming the header explicitly, the real failure:
Scenario 5 passing before implementation is the intended result: it documents that
AuthReturnTo.validate/1already refused cross-host, protocol-relative, backslash,bare-host and encoded-separator destinations. The guard needed no changes.
After — the same command, all five scenarios green. The pre-existing journeys over
the pages this touches (
confirmation_participation,join_source,global_header) stillpass unchanged.
Measured click count
"Or never" is not rhetorical — a person who does not remember the huddl's title has no
path back from the agenda.
The huddl page's own "Sign in to RSVP" was already 2 clicks. So the headline is not that A
makes the best path faster; it is that A makes the most obvious path — the topbar button
that looks like the way to sign in — as fast as the best one.
Full findings, the entry point audit, and answers to the spec's open questions (link-level
vs session capture,
JoinSourceTag, register-then-confirm) are indocs/research/post-login-landing-pocs.md.Merge Danger
Door: two-way.
Nothing is persisted, no schema or migration, no new route, no data-loading change. The
whole behavioral change is where two existing links point; reverting is deleting the
return_toattr.Blast Radius: narrow.
No pixels change — two already-styled buttons point somewhere better. Every page other
than huddl show and group show leaves
return_tonil and gets the bare paths it hastoday. The landing page's sign-in stays bare, correctly: there is no origin to return to.
The one risk worth naming is open redirect, and it is the reason validation sits inside
Layouts.appinstead of at the call sites. A scenario holds that guard.Deliberately out of scope: the bare
/sign-inredirects inlive_user_auth.ex(
:live_user_required,:admin_required) andlive/huddl_live.ex. Those fire when asigned-out person hits a page that requires an account, not from a huddl or group page.
Worth a follow-up; including them would inflate the baseline and make the comparison less
honest.
Part of #670
Verified by scenario (failing -> passing) and a clean
mix precommit(warnings-as-errors compile, format, full test suite,
credo --strict).Model: Claude Opus 5.5 (
claude-opus-5-5)🤖 Generated with Claude Code