Ferreteria/v0.5/stash: Difference between revisions
(→Design) |
|||
Line 15: | Line 15: | ||
The first one results in Ferreteria using two browser cookies (one for the Session ID, one for the stashed data) while the second uses only one (the Session ID loads the session data, including the stash). | The first one results in Ferreteria using two browser cookies (one for the Session ID, one for the stashed data) while the second uses only one (the Session ID loads the session data, including the stash). | ||
* '''Policy''': Since we're trying to minimize cookie-dependency, Ferreteria code currently only uses the Session record for stashing (although | * '''Policy''': Since we're trying to minimize cookie-dependency, Ferreteria code currently only uses the Session record for stashing (although Ferreteria provides services to use the cookie, which can then be used by apps). | ||
==Classes/Methods== | ==Classes/Methods== |
Latest revision as of 12:24, 24 March 2023
Ferreteria 0.5: stashing
|
About
Sometimes we need a quick way to preserve arbitrary transient information about a user-connection across a page-reload. This information is most commonly messages that result from actions taken by the user.
Messages/Output
This most often happens when a form has been submitted: Ferreteria prefers to do a redirect right after processing form (POST or GET) input in order to prevent accidental duplicate requests (which can happen if the user manually reloads after submitting a request). The page which processes the form may have transient output that it needs to convey to the user. Normally this would just be displayed on the screen -- but since the page will be redirected immediately after the output is generated, that output will be seen only briefly (or, more likely, not at all -- since the redirect is usually done instead of rendering the page output).
For this reason, the page system checks for buffered output, saves it in "the user stash", and then does the redirect. When a page is being rendered, the page system always looks for any stashed content to display, adding it at the top of any content it adds to the render. (This last part is currently not working, 2022-12-03.)
Login attempt
In order to make the login process a little easier, we stash the login-name (but not the password) when submitted so that the user doesn't have to re-enter the login-name when they mistype their password. (To find the relevant code, search Ferreteria's repository for "login-username".)
Design
Conceptually, there are two ways to "stash" data that needs to persist for a given browser session across plural http loads:
The first one results in Ferreteria using two browser cookies (one for the Session ID, one for the stashed data) while the second uses only one (the Session ID loads the session data, including the stash).
- Policy: Since we're trying to minimize cookie-dependency, Ferreteria code currently only uses the Session record for stashing (although Ferreteria provides services to use the cookie, which can then be used by apps).
Classes/Methods
- The message text gets submitted to
caPageContent->AddText
, which presumably adds it to the output buffer that the redirect process fetches from to toss over to the stash.- caPageContent->DoStashedRedirect(string $url) sends the page contents to the Stash.
- It looks like the stashed content is supposed to be retrieved by caPageContent->OnFigure()
- The PortUnit cStash class converts between formats.
- descends from PortUnit
- The PortCard cStash-field class
History
- 2022-12-19 Given EU regulations around cookies, I'm thinking it might be a "selling point" to be able to say that Ferreteria uses exactly one cookie, without any caveats. The ability for apps to use cookie-stashing for their own purposes will still be there; we just won't use it for any core Ferreteria functionality (in this case, displaying a message generated by a redirected page).
- 2022-12-18 Currently trying to track down which of the two designs I actually implemented. Tentatively, I may have done a mishmash of both, which could be why it isn't working right just at the moment...
- The message is, in fact, stashed in the cookie under
gmine-stash
(the Session ID is ingmine-session
). - It looks like the Session Calc class is trying to access it in the Session data, however... and it's not stored there. (The username is, though, for some reason.)
- The message is, in fact, stashed in the cookie under