- Shipped
- September 6, 2026 at 1:10 AM UTC
- Author
- Kamo
- Commit
- 5b2a96e
Somebody who presses Apply on the public careers board and already has an account reaches the register page, follows the sign-in link, and used to arrive on a dashboard with no sign of the thing they clicked. This carries the advert through the sign-in and puts them where the application form opens. TWO carriers, checked in that order. `?jobId=` is an explicit statement of intent on the URL — it survives a browser that will not keep the cookie, and it shows up in a bug report. The `kamo_apply_job` apex cookie kamo-register wrote is what makes ANY route to this screen work: the header link, the post-registration screen, a logout bounce, or simply typing the address. The user asked for "any link", and only the cookie delivers that. Bound to the UUID shape before it goes anywhere, so a hostile link cannot stuff arbitrary text into a login body. It authenticates nothing and grants nothing; SecurityService validates it against the organization's own board. The landing is /settings/member/me?tab=careers rather than the home screen, and that is what makes this work for an ACTIVE employee applying internally — they are not in the restricted tier, so nothing would redirect them and the prompt would never fire. An explicit ?next= still outranks it: that is the caller's own instruction. Sent on both completion paths. The workspace picker holds the uid in state rather than re-reading it, because the carrier is spent on success and a re-read would work only until something cleared it first; it rides to the workspace actually chosen, so naming a posting while entering a different organization records nothing. Spent on success, deliberately. The stamp RAISES the workspace's prompt flag — pressing Apply is a fresh answer that a flag lowered for another job last month should not override — so a carrier that survived would re-raise a prompt the member had already closed, on every sign-in until it expired.