[ic] Parsing of Querystring and security

[Mike Heins]

Quoting Andrew McBeath (andrew@ecombiz.co.nz):
> I am just playing / poking round in the depths of interchange...basically
> so I am happy that I know how the whole thing works. (I hate having stuff
> that I dont know how it works)
> This particular question was motivated by the whole dropped shopping carts
> and sessions issue...NOTE: I am not asking about how to get this working
> etc... I am of the opinion that shared SSL is not the best approach for
> Interchange and if it's not going to work why bust your boiler trying to
> get it going for the sake of a few bucks...
> 
> Anyway, my question is: whereabouts is the querystring (appended by [area]
> for example) generated and parsed - in particular where is the id=<session
> id> removed / made unavailable.  I found a lot of interesting bits like sub
> adjust_cgi() on line 1577 of /bin/interchange and it's callers.  Also many
> cool little bits in the /Vend/Session*.pm modules.
> 
> The closest I seem to have come the are the bits involving $Vend::FinalPath
> although this would appear to me to be after the Querystring /
> $CGI::values{id} have been parsed...again mostly interested in the session
> id value.

Actually this is done in Vend::Util::vendUrl as called by
Vend::Interpolate::tag_area().

If you (or anyone else) is interested in perusing the path things
take for a transaction, it basically goes:

Startup:

	Entry point is bin/interchange
	Parses options, if any
	initializations, i.e. read interchange.cfg, catalog.cfg,
          and friends, possibly opening some database tables onces
	  to read structures
	calls Vend::Server::run_server()
		Daemonizes IC
		calls Vend::Server::server_both
			Lots of junk in spawning various types of servers....

Running:

	Server loop is in Vend::Server::run_server and followed-down
        routines

	Server calls Vend::Server::connection(), which does the
        CGI stuff, then calls main::dispatch($http), where $http
	is the CGI and environment stuff
		
	main::dispatch does all of the session/database opening,
	parsing of path, determining action. 

	Normal action is to serve a page, the entry point
	for that is Vend::Interpolate::interpolate_html as
	called by Vend::Page::do_page()

	Vend::Interpolate::interpolate_html creates a
	new Vend::Parse object, which parses the IC page
	and executes any tags. This is frequently done elsewhere,
	such as in profiles, process FormAction, and ActionMap,
	and in any place where ITL needs to be interpreted.

Exiting:
	Server children block all signals when running a connection.
	When it comes back from a page, it will receive TERM and
	terminate; usually that is sent by the master server which
	will always accept a TERM or HUP except when actually forking
	the children.

That is a fair guide to getting started on a perusal of the source
code.


	
-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer