After creating a password-protected paste, the creator's browser should be able to view it without re-typing the password (e.g. cookie set at creation time). If not feasible right now, note it and defer.
FEASIBILITY NOTE (checked): unlock flow already sets a pw_ cookie (1h) on successful unlock. For creation: the client knows the password it just sent; after the API returns, the client can POST the password to the unlock endpoint to obtain the cookie before redirecting, so the creator never sees the lock screen. Small change, feasible.
After creating a password-protected paste, the creator's browser should be able to view it without re-typing the password (e.g. cookie set at creation time). If not feasible right now, note it and defer.
FEASIBILITY NOTE (checked): unlock flow already sets a pw_<id> cookie (1h) on successful unlock. For creation: the client knows the password it just sent; after the API returns, the client can POST the password to the unlock endpoint to obtain the cookie before redirecting, so the creator never sees the lock screen. Small change, feasible.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
After creating a password-protected paste, the creator's browser should be able to view it without re-typing the password (e.g. cookie set at creation time). If not feasible right now, note it and defer.
FEASIBILITY NOTE (checked): unlock flow already sets a pw_ cookie (1h) on successful unlock. For creation: the client knows the password it just sent; after the API returns, the client can POST the password to the unlock endpoint to obtain the cookie before redirecting, so the creator never sees the lock screen. Small change, feasible.