making external https requests to inworld scripts

[Sasun Steinbeck]

For historical reasons (compatibility) I am submitting a HTML form (from a browser) directly to an inworld script via HTTP, by setting the HTML action attribute in the form tag to the inworld script's URL. I'm experimenting getting everything switched over to HTTPS due to the fact that web browsers are now warning when submitting forms to a non-https address.

The big problem I've run into is that the LL certificate that inworld scripts use is self-signed and not accepted by Firefox and Chrome (ERR_CERT_AUTHORITY_INVALID).

This is quite easy to see, just create a script:

default
{
    state_entry() { llRequestSecureURL(); }
    http_request(key id, string method, string body) { llOwnerSay(body); }
}

Then just paste that URL into your web browser and you'll see the security error.

As a side note I'm also making http requests directly from my web server to inworld objects and THAT works fine since I can control the certificate validation process and approve it. LL makes that cert available for download for that purpose which is great. But I can't control the same cert validation process in all web browsers so I'm stuck.

The better solution which I've used ever since then is to never submit forms directly to inworld objects. Instead submit to your web host as usual, process the data, then send whatever data you need to the inworld script with an http(s) request or some other method. Plus processing large, complex forms can eat up all your script memory in a hurry. But this is a major rewrite of the code which I'd rather avoid as it's very bug free and working just fine.

I think I'm screwed... and a ton of code needs to be redone as it's a pretty complex form that requires a lot of processing and more importantly, this will completely break compatibility with updates in the future. Please tell me I'm wrong...

[bobsknief Orsini]

What not simply create a page and post the form to that page ?

The only thing you need to do on the page is grab the post data and use something like curl to send it to SL.

Edited November 18, 2022 by bobsknief Orsini

[Quistess Alpha]

2 hours ago, bobsknief Orsini said:

What not simply create a page and post the form to that page ?

because generally "pages" cost a lot of money if you don't already have one?

[Wulfie Reanimator]

Why exactly do you need to rewrite a lot of code to move from HTTP to HTTPS?

You said you're using a form and have your own web server, which POSTs data to another page, from which you send data to the LSL script.

When I recently tried/checked, you can't display any HTML content from LSL scripts unless they're visited exclusively from the in-viewer browser. You don't seem to be doing that if you can see security warning. How is the form served?

[animats]

15 hours ago, Sasun Steinbeck said:

The big problem I've run into is that the LL certificate that inworld scripts use is self-signed and not accepted by Firefox and Chrome (ERR_CERT_AUTHORITY_INVALID).

Nobody uses self-signed certs in production any more. LL is still using an old self-signed SSL certificate from 2005 , which uses an encryption system no longer supported. It expires in 2025, so there's a deadline.

Much SSL/TLS software doesn't like that antique cert. You have to configure OpenSSL to accept deprecated cryptosystems to use it, which the viewers have to do. In Rust, it's not supported at all, because that cryptosystem was deprecated years before Rust was created.

[Sasun Steinbeck]

I appreciate the solution of "just post to your web server" but you have no idea how much work that will be to re-architect how that data is processed from a script to the web server, that means a complete port of all that code, and there are other complications I didn't mention that simply make that a ton of work. It's ooooold but super stable code.

The form is served from from the website but simply posts directly to an LSL script. Seemed like a cool idea at the time, lol. Just post all that data to the script and boom, the script has all that data.

The real question is that doggone self-signed certificate not being recognized by the web browsers. I'm not a deep expert on certificates and how web browsers use them, but can't LL just... use a non-self-signed certificate for that? Would that fix the problem?

[bobsknief Orsini]

6 hours ago, Sasun Steinbeck said:

I appreciate the solution of "just post to your web server" but you have no idea how much work that will be to re-architect how that data is processed from a script to the web server, that means a complete port of all that code, and there are other complications I didn't mention that simply make that a ton of work. It's ooooold but super stable code.

The form is served from from the website but simply posts directly to an LSL script. Seemed like a cool idea at the time, lol. Just post all that data to the script and boom, the script has all that data.

The real question is that doggone self-signed certificate not being recognized by the web browsers. I'm not a deep expert on certificates and how web browsers use them, but can't LL just... use a non-self-signed certificate for that? Would that fix the problem?

Why a lot of work? Change 1 line in your HTML form and create a e.x. PHP page containing 10 lines of code.

On a side note, if its only you using it, in Firefox you can just click the advanced button and select continue and it works fine.

[Qie Niangao]

I gave up on llRequestSecureURL() until the Lab advances past the self-signed cert sloth. Honestly, the non-SSL warning looks less scary to end users than the self-signed cert one, and neither represents a realistic threat for anything I do in LSL. FWIW, they accepted my jira about this a few years ago. Not sure if they're waiting for a bribe or what.

[Sasun Steinbeck]

That seems to be the sensible path at this point... ugh. The non-SSL warning just looks scary to cusomters, like I'm doing something insecure, I hate that.

8 hours ago, Qie Niangao said:

I gave up on llRequestSecureURL() until the Lab advances past the self-signed cert sloth. Honestly, the non-SSL warning looks less scary to end users than the self-signed cert one, and neither represents a realistic threat for anything I do in LSL. FWIW, they accepted my jira about this a few years ago. Not sure if they're waiting for a bribe or what.

[primerib1]

On 11/19/2022 at 1:16 AM, Quistess Alpha said:

because generally "pages" cost a lot of money if you don't already have one?

You can use Oracle Cloud's "Always Free" offering.

Oracle will ask your credit card, charge you $1 then reimburse you, afterwards you can use the provided resource for free forever*. IIRC that includes 1 public IP address.

You'll have to install your own web server, though. And do some scripting (PHP/Python/Node.js). The script should be configurable to ignore 'insecure' (i.e., self-signed) certificates.

Also if you want your server to be secure, register for a domain name + grab a (free) Let's Encrypt cert.

* "forever" here means, of course, until Oracle changes its mind. However in Reddit I've seen many people saying that they have been using OC's "Always Free" resources for years with no issues and no payments.

[Sasun Steinbeck]

9 hours ago, primerib1 said:

You'll have to install your own web server, though. And do some scripting (PHP/Python/Node.js). The script should be configurable to ignore 'insecure' (i.e., self-signed) certificates.

If you look at the sample code I posted, you'll see that this is a completely different scenario. The web "server" is an LSL http_request() event. But yes I already allow the LL certificate in https requests from LSL scripts to my actual web server, so no problem there.