Adding default query parameters to generated links.

[Bill Moseley]

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@...

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Tomas Doran]

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


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Aristotle Pagaltzis]

* Tomas Doran <bobtfish@...> [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/>

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Bill Moseley]

On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <pagaltzis@...> wrote:

* Tomas Doran <bobtfish@...> [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@...

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Aristotle Pagaltzis]

* Bill Moseley <moseley@...> [2009-10-18 01:55]:

> On Sat, Oct 17, 2009 at 12:42 PM, Aristotle Pagaltzis <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/>

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/