A Wedding Invite Should Still Feel Like the Wedding at Sign-In

A guest could open a wedding invitation in Vowframes, see the couple's site, and then arrive at a generic platform sign-in page. The colours, names, and wedding frame disappeared just when the guest was being asked to identify themselves.

The authentication flow worked, but the journey felt disconnected. On 5 October, I followed that transition through the application and found that fixing the visual break also required checking which wedding the page could trust.

The redirect left the design behind

Vowframes serves wedding sites with different templates and moods. Guest authentication happens on the main platform. An invitation takes the guest through a wedding entry page, into central sign-in, and back to the wedding after authentication.

The wedding page already knew its template. The central sign-in page used the platform layout, with the platform's navigation and footer. The template had not failed to render; the redirect had moved the guest into a page that did not carry its design context.

Moving the sign-in form onto every wedding domain would have made the authentication problem larger. Google sign-in returned to the central platform, and the login cookie belonged there. I kept that architecture and changed the frame around the existing form.

The destination had to be trustworthy first

The sign-in page received a return destination in the URL. The old hostname handling could mistake a lookalike address for a wedding on our own domain. That mattered because the flow passed a one-time sign-in code back to its destination.

There was also a wedding name supplied through the URL. Displaying that text on the platform's own sign-in page gave an untrusted caller control over part of the explanation a guest would read.

I needed the page to resolve a real wedding before borrowing its identity.

The guest entry endpoints now bind the return destination to the wedding's own address. The frontend checks that origin and obtains the wedding's name and design from resolved tenant data. A query parameter no longer gets to invent the couple's name on the sign-in screen.

A separate check validates the relative path used after sign-in. That check belongs where the redirect is performed as well as where the path is passed along. Otherwise one careful entry page can be bypassed by reaching a later page directly.

These were reachable problems in the old flow. I did not establish that a real guest's account had been compromised.

One frame around the existing form

The result was a shared guest-authentication frame.

When sign-in or registration comes from a valid wedding destination, the page carries a wedding header with the couple's names, the wedding's colours, and a matching footer. The Vowframes form remains in its own light band between those sections.

The Atelier demo wedding uses fictional fixture names. Its wedding header and footer frame the shared sign-in form.

That separation was deliberate. The guest should recognise the wedding and also recognise where authentication is happening. I did not want fourteen copies of the login form, or fourteen template layouts trying to own its validation and error states.

Each template supplies a frame entry in the registry. The shared page chooses the appropriate frame after resolving the wedding. The full wedding layout can keep its own structure; sign-in needs only enough of that structure to maintain continuity.

An invalid destination gets the ordinary platform sign-in page. It cannot choose a wedding's appearance by asserting a familiar name in the URL.

I checked the journey across templates

I split the work into three changes: bind guest return destinations, validate post-login paths, and add the wedding frame. All three merged and went live on 5 October.

Before merging, the backend suite passed 766 tests and the frontend suite passed 346. Browser checks covered 68 local pages across all fourteen templates. On production, I checked a valid demo wedding, forged return destinations, registration, wedding pages, and invitation entry links.

Those checks served different purposes. A redirect test could establish that a hostile destination was refused. It could not tell me whether a guest recognised the wedding at sign-in. A screenshot could show the frame and still miss a dangerous return path.

There were smaller follow-ups. Long couple names could wrap onto two lines on phones. The preview hostname also needed reserving as a wedding slug. Neither changed the reason for the shared frame, and I kept them separate from the completed work.

I had already written about giving templates their own grammar. This time the challenge was a boundary between products: the wedding supplied the identity, while the platform supplied authentication. The guest now carries the wedding's visual context through that boundary, using data the platform has checked.