Hopbot log for 2007-08-05 - Helma IRC channel: #helma on irc.freenode.net

2007-08-05:

[4:54] <midnightmonste1> anybody know if req.postParams and req.getParams are real objects or some Java thing?
[6:58] <zumbrunn> midnightmonste1, in case you are reading the logs... req.postParams and req.getParams are Map objects, not plain JS objects
[7:01] <zumbrunn> (I agree we should change the docs to always be honest when the returned objects are really instances of a Java class and not prototypes)
[7:02] <zumbrunn> note that what you are probably looking for with req.getParams is really called req.queryParams
[7:02] <midnightmonster> right. thanks
[7:03] <midnightmonster> for(i in req.postParams) works, right?
[7:04] <zumbrunn> yes
[7:05] <midnightmonster> good deal. I was just writing a chunk of code while away from a conveniently running Helma, so I had to ask instead of check
[7:06] <midnightmonster> i wrote something to prevent cross-site request forgery and help reduce form spam
[7:07] <zumbrunn> is wobarcbot your soldier? or how did you know to pop in here right when I was talking to you?
[7:07] <midnightmonster> just coincidence
[7:07] <zumbrunn> hehe
[7:07] <midnightmonster> I was wondering about wobarcbot
[7:09] <midnightmonster> it has a method that can search an XML tree for forms with method="post". for each one it generates a unique token and saves it in the session. then it puts it in a hidden field inserted (someplace valid) in the form. so I just put a call to that method in my global template writer.
[7:10] <zumbrunn> smart
[7:10] <midnightmonster> it has another method that, if the request was POST, looks in the post data and session for a pair of tokens, checks the validity and redirects back to the referer with a res.message if there's a problem anywhere
[7:11] <midnightmonster> HopObject.onRequest = PostManager.onRequest; // tada, site-wide cross-site request and spambot protection
[7:13] <midnightmonster> (the places where I write prototype-specific onRequest functions obviously I have to mention it again, but that's just PostManager.onRequest().)
[7:13] <midnightmonster> I'll post the code once I test/debug it--it hasn't actually been run yet.
[7:16] <zumbrunn> this.__proto__.__proto__.onRequest()
[7:17] <zumbrunn> calling super, kind of
[7:17] <midnightmonster> ^ runs the .onRequest of the type "this" extends, right?
[7:17] <zumbrunn> right
[7:19] <midnightmonster> if I write a more complicated HopObject.onRequest or SomeOtherTypeThatGetsExtended.onRequest I'll use that. for now I think it's clearer just to call PostManager.onRequest()
[7:21] <zumbrunn> ...of the type "this.__proto__" extends, actually, but that's what you meant, I guess
[7:22] <midnightmonster> this is just one more thing that pervasive e4x makes reasonable. I could have done this in PHP by regex-parsing the output (brittle) before printing it or shoving it all into an XML parser and DOM-manipulating it (expensive), but it would have been brittle and/or expensive.
[7:22] <zumbrunn> yes!
[7:23] <zumbrunn> I have a feeling we will discover many neat things like this
[7:24] <midnightmonster> (and I only could have done it in PHP because of the framework I had put together. there wouldn't be a sane way to install a standard bit of filtering across all POST requests otherwise)
[7:25] <midnightmonster> afk for now
[7:39] <midnightmonster> how long do sessions stay alive, and how can I set that?
[7:40] <zumbrunn> 30 mins, I believe
[7:40] <zumbrunn> sessionTimeout
[7:41] <zumbrunn> http://helma.org/docs/guide/properties/listall/
[7:43] <midnightmonster> also, just realized I can solve the problem of people who just take a long time to fill out a form (or walk away and come back) by having PostManager install an exchangeToken action on Root. then a small script on the client can do an XHR a few minutes before the session/token runs out to /exchangeToken with the old token as an argument and get a new token to replace it.
[7:43] <midnightmonster> 'cause dang it annoys me when I come back to something later and submit a form and it tells me my session is expired. I'd hate to inflict that on people
[7:45] <zumbrunn> yep, but it still could happen if they are offline for a while
[7:45] <zumbrunn> you could return the form the way it was filled out, for resubmission with a valid token
[7:46] <midnightmonster> yeah. that's what I needed to walk the post and get params for
[7:47] <midnightmonster> bbl
[15:02] <decke> guten abend
[15:19] <zumbrunn> good evening
[15:19] <zumbrunn> oder guten abend, decke .-)
[15:20] <decke> oh an english channel... okay good evening ....
[15:20] <zumbrunn> deutsch geht auch
[15:20] <decke> seems like i got bitten by an nested macro bug in 1.6
[15:20] <zumbrunn> hmm
[15:20] <zumbrunn> don't know about that yet, I don't think
[15:21] <decke> zumindest scheint folgendes: <img src="<% this.href type=<% param.type %> %>" />
[15:21] <decke> mir unter freebsd und linux threads ziemlich zu beschäftigen...
[15:22] <decke> die genauen gründe dafür versteh ich derzeit selbst noch nicht.... zumindest nach einem flush oder restart funktioniert alles...
[15:22] <decke> sobald dann ein image upload (samt einiger funktionalität wie resize etc.) getätig wurde gibts bei diesem nested macro nur mehr timeouts....
[15:23] <decke> einen möglicherweise aussagekräftigeren stacktrace hab ich auch schon gesammelt...
[15:23] <zumbrunn> den schickst du am besten auf die mailing liste
[15:24] <zumbrunn> oder machst gleich einen bug eintrag
[15:24] <decke> http://helma.pastebin.com/m5e32218b
[15:24] <decke> ich hab ihn mal hochgeladen...
[15:24] <decke> in der hoffnung, dass er hilfreich ist...
[15:25] <decke> meine erste hoffnung war, dass es ein freebsd jdk bug ist... aber habs leider gerade mit linux und jdk 1.6.0_01 verifiziert ...
[15:25] <zumbrunn> komisch, dass das zuerst geht und dann nach dem image upload nicht mehr
[15:26] <decke> ja das versteh ich noch ned ganz...
[15:26] <decke> aber ich kann den zusammenhang nicht erkennen...
[15:27] <decke> und wie gesagt pro aufruf der page kommt dann ein thread (TX-appname)
[15:27] <decke> der mit so einem stacktrace hängen bleibt...
[15:27] <decke> und ordentlich cpu verbraucht
[15:27] <decke> mit helma 1.6 und auch dem neuesten snapshot von heute....
[15:28] <zumbrunn> andere nested macro aufrufe funktionieren?
[15:28] <decke> andere gibt es nicht...
[15:28] <decke> ist derzeit die einzige stelle ...
[15:29] <zumbrunn> am besten als bug eintragen: http://helma.org/bugs/
[15:29] <decke> ja schon dabei...
[15:29] <zumbrunn> mir ist wie gesagt weder das problem noch ein workaround bekannt
[15:30] <decke> mhm okay danke...
[15:31] <decke> mal schaun vielleicht kann ich eine kleinere app bauen die das problem etwas verständlicher macht....

 

 

In the channel now:

Logs by date: