I don't know how hacky this is, but by removing the first condition on
the "bi" below (furnace.sessions) my problem is "solved" (I can
happily edit the wiki and never get back to the login page :):
: verify-session ( session -- session )
sessions get verify?>> [
dup [
dup
[ client>> remote-host = ]
[ user-agent>> user-agent = ]
bi and [ drop f ] unless
] when
] when ;
My question is: suppose that "optionally not comparing remote-host"
was the fix, what would be the correct patch ? To add a slot that
tells me if I should verify the remote-host, or a dynamic variable
configuring that?
Cheers,
Hugo
On Sat, Nov 14, 2009 at 3:26 PM, Stefan Scholl <[email protected]> wrote:
> This problem doesn't affect every visitor of a page. That's why
> it could be hard to track down.
>
>
> On #concatenativ someone reported that he had problems with the
> login on concatenative.org. He checked his IP and it was changing
> between requests. Not the normal change with some ISPs that give
> you a new IP every 24h.
>
> That's something I remembered hearing from AOL users behind web
> proxies.
>
> In furnace.sessions the remote IP and User-Agent string are
> stored in the session and checked when the session gets
> validated.
>
> And this was a problem with TBNL (predecessor of the Common Lisp
> webserver Hunchentoot), too. Edi Weitz made it optional with the
> default to OFF:
>
> *use-remote-addr-for-sessions*
>
>
> If this value is true (the default is NIL) then the
> 'real' remote address (see REAL-REMOTE-ADDR) of the
> client will be encoded into the session identifier,
> i.e. if this value changes on the client side the
> session will automatically be invalidated.
>
> Note that this is not secure because it's obviously
> not very hard to fake an X_FORWARDED_FOR header. On
> the other hand, relying on the remote address (see
> REMOTE-ADDR) of the client isn't an ideal solution
> either because some of your users may connect through
> http proxies and the proxy they use may change during
> the session. But then again, some proxies don't send
> X_FORWARDED_FOR headers anyway. Sigh...
>
> http://weitz.de/tbnl/#*use-remote-addr-for-sessions*
>
> and
>
> *use-user-agent-for-sessions*
>
>
> If this value is true (which is the default) then the
> 'User-Agent' http header (see USER-AGENT) of the
> client will be encoded into the session identifier,
> i.e. if this value changes on the client side the
> session will automatically be invalidated.
>
> While this is intended to make the life of malicious
> users harder it might affect legitimate users as
> well: I've seen the this http header change with
> certain browsers when the Java plug-in was used.
>
> http://weitz.de/tbnl/#*use-user-agent-for-sessions*
>
>
>
> --
> Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Factor-talk mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
