HandleURL to AppSession alternatives?

Targets Web
1

I want to implement a light-weight login screen using HandleURL and pass off to a full Web App session if the login is successful. This should be a lot more resistant to DOS attacks for publicly accessible apps.

However, as discussed in the SpecialURL vs HandleURL thread, at this time, a new Web App session is not start-able from the HandleURL event, and the auto browser redirect workaround is now broken by FireFox et al.

I want to keep the entire solution within a standalone Web App without having to resort to Apache/PHP for log-ins.

Are there any other ways to do this within XOJO?

Thanks,

Eric

2

[quote=191326:@Eric Wilson]I want to implement a light-weight login screen using HandleURL and pass off to a full Web App session if the login is successful. This should be a lot more resistant to DOS attacks for publicly accessible apps.

However, as discussed in the SpecialURL vs HandleURL thread, at this time, a new Web App session is not start-able from the HandleURL event, and the auto browser redirect workaround is now broken by FireFox et al.

I want to keep the entire solution within a standalone Web App without having to resort to Apache/PHP for log-ins.

Are there any other ways to do this within XOJO?[/quote]

I was not aware that Refresh was broken in FireFox. It sadly appears to indeed be the case.

I was going to suggest an approach similar to Php, since after all what does HandleURL is similar, but as HandleURL, unlike PHP or Perl does not have anything like Location: built in, it now looks impossible.

Yet, here is what I would try :

In the HandleURL event, I would identify two Paths :

/Login/ serves a login page, basically an HTML form with the familiar login name and password and a button. Form Action points to /LoginVerify/ where the app checks the validity of the credentials, and if OK, displays a new page.

At that stage, I would place a Refresh in the OK page for most browsers to take the user to the app, and display a link into it for the user to access the app.

I just filed this request :
39553 - Add ShowURL in Xojo Web HandleURL

Until now I have used the HTML redirect with Refresh, but it got broken in FireFox. So now there is no way to send FireFox users to an URL.

Would it be possible to add ShowURL inside HandleURL, analogous to what is provided by Location: in Perl or Php ?

<https://xojo.com/issue/39553>

3

Can’t you use:
Request.status=302
Request.Header(“Location”)=
return true

4

That works perfectly with Firefox, and other browsers as well.

Splendid.

Thank you Antonio.

5

Will give it a go, thanks!

6

Yes, redirecting this way still works with Firefox, but upon reflection, this workaround isn’t suitable for a login screen that shields a Web App from hackers. This seems to me because the Web App becomes exposed to the public through the Location URL, so redirecting only kicks the can down the road from a security standpoint.

I will however let people know Antonio has found a way to achieve a Firefox redirect in the HandleSpecialURL vs HandleURL thread. This is because the redirect is still a good thing for people who want mycompany.com/reservation to go to mycompany.com/bookings etc. Thanks for that Antonio.

Any other ideas for a login screen that shields a Web App?

7

[quote=191421:@Eric Wilson]Yes, redirecting this way still works with Firefox, but upon reflection, this workaround isn’t suitable for a login screen that shields a Web App from hackers. This seems to me because the Web App becomes exposed to the public through the Location URL, so redirecting only kicks the can down the road from a security standpoint.

I will however let people know Antonio has found a way to achieve a Firefox redirect in the HandleSpecialURL vs HandleURL thread. This is because the redirect is still a good thing for people who want mycompany.com/reservation to go to mycompany.com/bookings etc. Thanks for that Antonio.

Any other ideas for a login screen that shields a Web App?[/quote]

As it stands, the 302 redirect is initiated only when the user has legitimately logged in, and at no point has to appear anywhere else than in your HandleURL code. Ultimately, anyway, you do have to take the legitimate user to the app.

If the login procedure including your handleURL app is not on the same domain as the webpages app, you should be pretty safe.

8

Michel that may be so but a hacker could use a legit account to gain the ip address or URL for the Web App to target DOS, and a full session-based Web App would be a lot more vulnerable than the HandleURL-based login screen protecting it.

9

FWIW, you probably shouldn’t be relying on any http server to provide protection from this type of attack anyway. Typically you’d use a firewall or other upstream mechanism for that.

10

At any rate if the hacker gains access to the app URL how are you going to protect it from an attack on its root URL ? HandleURL works only if a subdirectory is used.

11

That’s not the case. HandleURL can intercept the app’s root level calls too. Request.Path = “”

12

Neat :slight_smile:

13

True about needing a firewall etc, however those can take time to detect distributed attacks. It would also be nice to be able to start a session under program control for performance reasons, and to avoid any other redirect issues that may arise in the future.