Login via URL parameters

[Rob Mikkelsen]

I have a page within my application that can look up all the "hits" on an aircraft on my FAA web sites.  This has proven a valuable tool for locating lost aircraft or downed aircraft. To expedite the search, several sites would like to implement a link directly to this page. 

I had dropped a routine in the procedure setup of the page to check for the user ID and password in the URL and log the individual into the site but this has proven unsuccessful.  It works on the IndexPage, but that page does not require a login to access.  The aircraft locator is a page where login is required, so apparently the web handler does not recognize its existence.

Where can I embed the code within the web handler (or is it the server routine?) to allow a single pass login so the site can access the page directly?

Thanks!

Rob

[Rob Mikkelsen]

After a bit of searching, I seem to have found it.

In Web Handler procedure:
ThisWebWorker._HandleGet after parent call

This does exactly what I need.  I can send the user ID and password as parameters on the URL and the system logs into whatever page I request (providing I have access rights to that page).  I have recommended a restricted account to limit where the user can go after accessing the page.  If there is a more efficient way of doing this, please don't hesitate to post it.

Cheers!

Rob

[Bruce]

Hi Rob,

HandleGet is fine - although would not work if the request was made via a Post. ie it limits your external person to make it a _link
- not a button.
If you wanted it to work for POST's or GET's then ProcessLink before parent call would be perfect.

Incidentally this logs the person into the whole site, so I recommend using an SSL page for this. Also you might want to limit the login to "only if on a SSL connection" - by checking self.secure = 1

Cheers
Bruce

[Rob Mikkelsen]

Bruce,

SSL is ultimately where we are headed.  However, since we would not be revealing any state secrets should the userID/Password be intercepted, we decided to implement without the SSL.  I concur, however, that logins should ALWAYS be SSL.

Thanks!  I will make the change although I don't foresee anyone requesting the page via a POST procedure.  However, I may decided to do so myself sometime so it will save another round of head-scratching...

Rob