I've been looking into the persist plugin a bit (a good bit actually!) and I've stumbled on to some problems.
1) The BOLTconfig function calling the $BOLTloginPages value doesn't have a default value ( 'login', second parameter ) and therefore you get a glitch. At one point it was probably in the core site.config page, and then later stripped out. So without the default value set, it glitches. To use as is, set loginPages: login in site.config. But I'm changing all that... 2) There is a security vulnerability I won't detail, mostly because it is somewhat embarrassing. :) But it can be solved easily enough. 3) I'm thinking we ought to just use site.persist rather than site.persist.login. Unless someone can think of a reason not to change the location of the key page. Why bury it in a third level, if there is no page above it, or sister pages to justify it? It looks weird in a toc kind of display. 4) The patterns needed to be a lot smarter. I guess my skills have improved with practice. 5) If we change how the script works just a bit, I think we can dramatically simplify the code and getter more reliable results. For instance, in regards to the command--if we require the user to be logged in, I trim out lot's of stuff, and tighten security. This means to create the cookie, I must put [session persist "+1 week"] AFTER the login command (or [session persist] to set for +15 days, the new default config value for persistDefault). To clear the cookie, put [session persist clear] BEFORE the logout command. As long as you remember they have to be logged in to work, everything gets easy. 6) For the [(persist)] function I'm wondering if it should continue renewing the cookie every page load or just use it to log a user in. Not only does it seems highly inefficient, but dropping it allows me to cut out almost half the code! If we go that direction, a person would log in, click the remember me box, and then be automatically logged in for 2 weeks or however long you specify (even +1 year), but would have to relog in after that time frame was up. I notice this is how Gmail works. Every so often the cookie expires. Note: there is a [(persist reset="+1week")] parameter I decided to leave in, that can be used to extend the cookie. It only works though, when someone is being logged in automatically using the persist function. 7) I decided to strip the code writing info to the site.persist page to a separate function, and then put hooks in the persist function that can be used when someone is logged in to either set a cookie [(persist '+2 weeks')] or clear it [(persist clear)] to remove a cookie. (Just like the form command). This could make some interesting automatic behavior. But to prevent any weird looping things, I'm going to block this function from working as a login function, when $args[1] is set to one of these values. 8) The other thing, there doesn't seem to be any self cleaning of the site.persist page. As in old entries, never get purged. This might not be a problem on a site with few users, but on a large site, with hundreds or thousands, I think there should be some automatic system for cleaning. So in this release I am going to add an expires timestamp to each entry and matching the cookie. And then purge expired ones, every time the page is reset. I pretty much have this all working nicely on my computer. I'll post to the plugins page later today after I have had a bit of time to test it all. But thought I would get everyone's feedback before doing so. The changes to seem to be a much better design My schedule should free up some Wednesday or so. Our next release is loaded with bug fixes and a fair bit of rewiring under the hood. But it will feel good to get the backlog cleared out. Where did all these issues come from? Thought we had things running pretty smooth... :) Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
