Ferreteria/v0.5/stash: Difference between revisions

From Woozle Writes Code
Jump to navigation Jump to search
No edit summary
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 the functions to use the cookie instead can be used by apps).
==Classes/Methods==
==Classes/Methods==
* The message text gets submitted to <code>{{l/ver/class/method/both|caPageContent|AddText}}</code>, which presumably adds it to the output buffer that the redirect process fetches from to toss over to the stash.
* The message text gets submitted to <code>{{l/ver/class/method/both|caPageContent|AddText}}</code>, which presumably adds it to the output buffer that the redirect process fetches from to toss over to the stash.

Revision as of 17:22, 16 February 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 the functions to use the cookie instead can be used by apps).

Classes/Methods

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 in gmine-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.)