On Tue, Dec 11, 2012 at 9:02 AM, Ashley Sheridan
> On Tue, 2012-12-11 at 08:46 -0400, Paul Halliday wrote:
> I have a form that has username and password fields. While the form
> exists and contains various other fields the most common mode of
> operation is to have the form auto submit if it has enough arguments
> in the URL. So, someone is using an external program that has links
> wired as such:
> and when they hit that URL it sees it has enough arguments, fires and
> returns the result.
> Client <-> Server is encrypted, can I toss these into session variables?
> The user could be coming from multiple frontends and it would be nice
> to forgo the user/pass in the url; give the username focus on the
> first visit let them drop their creds and then store them into the
> session so with each subsequent hit they can just get their results.
> Make sense?
> Note: I need to pass the credentials to an external app each time a
> request is made.
> Paul Hallidayhttp://www.pintumbler.org/
> It looks like you're trying to re-invent authorisation procedures.
> Typically, the first request logs a client in and retrieves a hashed key,
> which is then used in all subsequent requests so that the server can
> correctly verify the client. You can do this the way you suggested with the
> session, but you must ensure that the session id is passed across to your
> script by each of the connecting clients. That will be done either as part
> of the head request, or as an extra parameter in the URL.
I understand that. The username/pass are NOT for authentication to the
form, they are being passed to exec();
So, I guess in this context they are just arguments.
Providing I handle the session properly, does it make sense to toss these
arguments into session variables?