2007-10-18:
[1:44] <BSlivka> I wonder if the helma dev team have an awareness of Chris Date's work[5:24] <aiba> so i'd like for my users to be able to login and say "remember me for 2 weeks". how would one implement this with helma sessions? do i set their session cookie to expire in 2 weeks (and lose it if it i restart helma), or do i create a new cookie and store that in a database, or is there another way?[5:32] <aiba> come to think of it, any time i restart helma all my users get logged out?[5:33] <BSlivka> depends on how you're persisting your data I suppose.[5:34] <BSlivka> If all your users are transient hopobjects, then yes, they'll get logged out and you'll lose session data every time you restart[5:36] <aiba> the users objects are not transient, but i'm assuming the association created by session.login() is transient[5:40] <aiba> ok i'll just create my own login cookie and keep a login table in the database. not the end of the world.[5:40] <BSlivka> I'm just a helma newbie, but looking at the documentation...[5:41] <BSlivka> login causes user to be a property of the session object[5:41] <BSlivka> if the session is persisted, then so is the association, I presume.[5:41] <BSlivka> The remaining question is, "are session objects persisted"[5:41] <aiba> i dont think the session is persisted anywhere, unless it's in helma's XML database on disk somewhere[5:41] <aiba> it's certainly not persisted in my sql database[5:42] <BSlivka> Well you could create a session folder[5:42] <BSlivka> and a type.properties, wouldn't that persist it?[5:43] <BSlivka> i've seen folders with random looking strings appear in helma's db folder[5:43] <aiba> i dont know enough about helma to know if/how that would work[5:44] <BSlivka> maybe those are sessions[5:45] <aiba> for what app?[5:45] <BSlivka> just in the root DB folder[5:45] <BSlivka> eh, but I haven't made an app with a login() call in it yet[5:45] <aiba> i thought that folder was organized as helma-1.6.0/db/<appname>/[5:46] <BSlivka> Yeah it appears to be[5:46] <BSlivka> but I've also got /db/[randomstring]/[5:46] <aiba> oh, haven't seen that[5:46] <aiba> i think i'm just going to create a login table and my own login cookie[5:47] <BSlivka> fair enough.[5:47] <BSlivka> Let me know how it goes.[5:47] <aiba> session.login() will still be useful for associating users with sessions and session.data, etc. but if a user is not logged in, i'll first check for a login cookie to see if he should be.[5:48] <aiba> and this way i can restart helma without logging out all my users[5:50] <BSlivka> I thought I saw a session folder in one of these helma apps, but I can't find one now.[5:50] <BSlivka> maybe I was imagining...[5:54] <BSlivka> Hrmn, it's a property of the global object.. and I guess the global object is transient[5:57] <aiba> interestingly, there appears to be an undocumented "persistentSessions" application property[5:57] <aiba> i'm reading the helma source for Application.java[5:58] <aiba> which does create /db/sessions/[5:58] <aiba> so maybe you did see that folder[6:01] <BSlivka> Zumbrunn told me that there was a bug in the document generator that dropped some of the aspects... and sent me..[6:01] <BSlivka> http://dev.helma.org/trac/helma/browser/apps/reference/trunk/coreEnvironment/session.js[6:05] <aiba> correction: it stores it in /db/<appname>/sessions[6:06] <BSlivka> hah[6:06] <aiba> document generator?[6:07] <BSlivka> err documentation- Helma is self documenting, to a certain extent.[6:07] <BSlivka> the documentation is done inline in the source code[6:07] <BSlivka> and that's transformed to html, similar to jdoc[6:07] <aiba> oh, gotchya[6:07] <aiba> this is for the purpose of listing all the properties of session object?[6:07] <BSlivka> Reading the logs- he says that session.logout() got dropped for some reason[6:08] <BSlivka> It's the process that generates the "reference" section of helma.org[6:08] <aiba> ok, i see, but this bug is unrelated to persisting sessions right?[6:08] <BSlivka> right[6:09] <BSlivka> just related to generated the documation OF sessions, and specifically session.logout() so as it turns out, irrelevent to the conversation[6:13] <aiba> :)[7:10] <zumbrunn> aiba, BSlivka, there is a built -in way to persists sessions in helma[7:10] <zumbrunn> persistentSessions[7:10] <zumbrunn> Setting "persistentSessions=true" in the app.properties file will attempt to preserve sessions through an application reset or server shutdown/restart, except for sessions that have expired in the meantime. Optional read-only property, default is false.[7:11] <zumbrunn> http://helma.org/docs/guide/properties/listall/[7:11] <aiba> yep, discovered that by looking at Application.java. thanks![7:12] <aiba> oh, this list of properties is sweet. i hadn't noticed it before.[7:13] <aiba> so my next question: is there a way to take a particular session and say, "make this a permanent cookie and don't expire it for 2 weeks"?[7:14] <aiba> (i'm trying to implement "remember me on this computer" checkbox for the login form)[7:20] <BSlivka> thanks zumbrunn[7:47] <zumbrunn> aiba, there is sessionTimeout[7:47] <zumbrunn> This determines the time (in minutes) after which an inactive session becomes invalid. The default is 30 minutes.[7:47] <zumbrunn> but that's probably not what you are looking for in this case[7:48] <zumbrunn> instead, you could create a custom cookie to do an autologin when the user returns[7:49] <zumbrunn> (looking for that cookie in an onRequest handler)[8:03] <aiba> thanks zumbrunn. i'll use a custom cookie for autologin.[10:03] <aiba> is there a way to flag a cookie secure with res.setCookie()?[10:09] <aiba> hm, looking at ResponseTrans.java and CookieTrans.java, it appears the answer is no.[10:10] <aiba> this is a pretty serious limitation. anyone know a way around it, maybe by setting a header directly or something?[10:32] <aiba> oooh, i can create my own Packages.javax.servlet.http.Cookie and then add it manually with res.servletResponse.addCookie().[10:33] <aiba> (and call the setSecure() method on Cookie)[12:46] <rist> hi, just spotted a mistake in the helma docu[12:47] <rist> http://helma.zumbrunn.net/reference/core/MimePart.html#writeToFile doesn't return void but the complete path of the written file[12:47] <rist> (and seems to attach the file's current fileextenstion to the second argument)[12:48] <zumbrunn> ok, I'll fix the docs[12:49] <rist> thanks
In the channel now:
Logs by date: