> > can you explain me why this affects the url_scanner ?
>
> i'm a liar;-)
i know ;)
>
> no, if architected smart it would make no real difference.
> but - do we really want it? session-data belongs into the
> session. this new function just allows you to identify
> different browser-windows within the same session (if used
> right). i really see no point in extending it -but- wait....
yes, you are right, session stuff belongs into the session but i can show you lots of
examples where i can't put things
into the session but have to send it via get/post. e.g. i have a multistep enrolment
procedure where i generate a
access-key for each form which is stored in the session _and_ in the webpage and only
if they are both the same the form
can be submitted. the submit-action script immediately generates a new access-key
which prevents the form to be
submitted twice and which allowes the next enrolment step to be performed.
i also have samples where i need more than one var to be appended.
>
> we could of course add a real API to the trans-sid module
> that allows for
>
> url_rewriter_add('bal' , 'hallo');
> url_rewriter_add('SID' , session_id());
that would be ok too.
> etc etc.. so you could run you session in hidden vars on the
> page - and the security nightmare starts again (ppls will use
> that to store stuff in hidden vars that _belong_ in the
> sesseon).
... and if people set empty root passwords their boxes will be vulnerable too ...
> on the other hand i think it might be useful to run the
> session using a cookie and still be able to add things (like
like ?
harald
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
