FAQ
I have a Catalyst application that is only handling part of the URL space of
an existing application. The existing application saves some state
information in the query string of every link.
Therefore, the query string must be maintained when linking from the
Catalyst part of the app back to the non-Catalyst part of the application.

There's always a session available to save the parameters while in the
Catalyst app. It's a know list of parameters that must be preserved.

What do you recommend? Override uri_for() and make sure that every URI
generated includes the query paramters, even links within the Catalyst part
that will not use the parameters?

Or save the query parameters in the session at the start of the request and
create a separate wrapper method around uri_for() for creating URLs back to
the non-Catalyst part of the application that adds the query parameters back
in?


--
Bill Moseley
moseley@hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091012/a8d8e787/attachment.htm

Search Discussions

  • Tomas Doran at Oct 12, 2009 at 9:54 pm

    On 12 Oct 2009, at 21:36, Bill Moseley wrote:
    What do you recommend? Override uri_for() and make sure that every
    URI generated includes the query paramters, even links within the
    Catalyst part that will not use the parameters?
    I'd very likely go with this myself.

    You can apply it as a role, and then trivially remove it later, it's
    wrapping one method and so low impact, and there are no negative
    consequences if your session goes away for any reason..

    Just feels like less moving parts to me...

    The other approach is however totally valid (and in some ways cleaner,
    as you don't have to carry parameters you aren't using everywhere etc)..

    Cheers
    t0m
  • Aristotle Pagaltzis at Oct 17, 2009 at 7:42 pm

    * Tomas Doran [2009-10-13 00:00]:
    I'd very likely go with this myself.

    You can apply it as a role, and then trivially remove it later,
    it's wrapping one method and so low impact, and there are no
    negative consequences if your session goes away for any
    reason..

    Just feels like less moving parts to me...
    Less implicit state on the server = better HTTP style:

    ? Easier to scale: at the app level, no session to replicate
    between web servers or communicate via the DB; above the app
    level, easier to use proxies to selectively route/cache stuff
    by inspecting URIs

    ? Easier to test and automate: no need to drive a (maybe long)
    sequence of requests to put the interaction into the right
    state

    ? Better user experience: allows multiple tabs with different
    interaction state in each

    ? More detail in server logs: better data mining opportunities

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Bill Moseley at Oct 17, 2009 at 11:53 pm

    On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis wrote:

    * Tomas Doran [2009-10-13 00:00]:
    I'd very likely go with this myself.

    You can apply it as a role, and then trivially remove it later,
    it's wrapping one method and so low impact, and there are no
    negative consequences if your session goes away for any
    reason..

    Just feels like less moving parts to me...
    Less implicit state on the server = better HTTP style:
    I agree with you here.

    � Easier to scale: at the app level, no session to replicate
    between web servers or communicate via the DB; above the app
    level, easier to use proxies to selectively route/cache stuff
    by inspecting URIs
    I wish that was possible, but in this case the session data structure is a
    beast.
    I'm currently pulling data from the existing app's session and populating
    $c->session for the data
    that needs to be used.


    � Better user experience: allows multiple tabs with different
    interaction state in each
    This is something you have mentioned before, and I'm on board with this. I
    assume you mean a session id in the URL, right?

    http://en.wikipedia.org/wiki/Session_fixation#Do_not_accept_session_identifiers_from_GET_.2F_POST_variables

    recommends not having a session id in the URL. One way to mitigate risks is
    by changing session ids often (as recommended by the article). But, assumes
    web requests are serial in nature, which they are not. So, it's not that
    simple to just send back a new session id every request or ever few minutes.



    --
    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091017/e7da53ac/attachment.htm
  • Aristotle Pagaltzis at Oct 18, 2009 at 2:06 pm

    * Bill Moseley [2009-10-18 01:55]:
    On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis wrote:
    ? Better user experience: allows multiple tabs with different
    interaction state in each
    This is something you have mentioned before, and I'm on board
    with this. I assume you mean a session id in the URL, right?

    http://en.wikipedia.org/wiki/Session_fixation#Do_not_accept_session_identifiers_from_GET_.2F_POST_variables

    recommends not having a session id in the URL. One way to
    mitigate risks is by changing session ids often (as recommended
    by the article). But, assumes web requests are serial in
    nature, which they are not. So, it's not that simple to just
    send back a new session id every request or ever few minutes.
    No, I mean passing all the necessary state along in the URI
    explicitly ? not a key to a bit of catch-all state on the server.

    If there is so much state as to make this impractical, then have
    the client POST the stuff and have the server create a resource
    to represent that specific collection of state. Eg. if a search
    query is too complex, have it POST the query and store it under
    a search ID that the client then uses to browse the results. The
    difference from putting a session token in the URI is that they
    can create several different queries and then browse the results
    of each in a different tab, at the same time, without the tabs
    wiping out each others? state.

    The session is a sinle catch-all grab bag for all sorts of state,
    basically a big pile of global variables. It has all the same
    problems as functions that use global variables ? you can?t call
    it with different values when other parts of the code are also
    using the same variable. In the same way putting state in the
    sessions mean you can have only one search query, only one
    shopping cart, only one of each other kind of state, at once,
    because there is only one session. If you create resources
    explicitly for each aspect of state, then you can have as many
    of that kind of state at the same time as you want, much like
    passing a parameter to a function instead of having it look at
    a global variable.

    Of course, if it?s feasible to just pass all the data via the
    URI you should still do it that way. That?s *always* the better
    solution when there is no specific reason against it, because it
    makes the interaction state identifiable by URI, just like
    creating resources does, but without the need to persist anything
    on the server.

    Note how in both of cases (URI parameters and resources), the
    interaction state is identified explicitly by the URI. That?s how
    different tabs can have different state ? because each one has
    a different URI in the address bar. For the same reason it?s also
    possible for the user to bookmark any specific point in the
    interaction. If you hid the state in a grab bag session, then
    that wouldn?t be possible.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 12, '09 at 8:36p
activeOct 18, '09 at 2:06p
posts5
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase