Jump to content

Oz Linden

Lindens
  • Content Count

    363
  • Joined

  • Days Won

    1

Oz Linden last won the day on April 25 2018

Oz Linden had the most liked content!

Community Reputation

885 Excellent

About Oz Linden

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The cloud uplift version does not add or subtract any features. There are some changes that may affect the remote service - see this post
  2. something like this is best dealt with as a Support request, so I'll leave it to them
  3. This is most likely DNS caches not updating to your new server uniformly; it should correct itself in time.
  4. We're working on it. We only recently got our tools updated sufficiently to do so (some part of the most recent Xcode is needed).
  5. Really, "source authentication" that was just an IP address check wasn't worth much to begin with. Yes, it would filter out some of the annoying but unsophisticated generic attacks on web servers, but it didn't really tell you that requests were coming from the scripts you expected (anyone on any region with any script would have the same IP range that legit scripts did), or that it wasn't an attack. If that's what you had, no change is needed to the in-world content to keep it working because just removing the IP address check at the server will allow the in-world scripts to work. Adding
  6. It doesn't change that setting at all (at least not yet). The point of that setting is to use the internal browser for 'trusted' content created by the Lab. The fact that web servers implemented by Residents in LSL ended up in a subdomain of 'lindenlab.com' was actually a flaw in that design, and part of why we're (nearly) eliminating the use of the corporate domain for addressing of things within SL (to reassure viewer developers: we're not changing the domain of the login servers - that would be too much trouble). Whether or not there should be a setting that adds services within 'secon
  7. We can probably lengthen that (assuming that doesn't result in unmanageable litter); I'll look into it on Monday.
  8. The script can add a custom header that has that signature in its value; there's no need for the proxy to be involved at all.
  9. We don't own the IP addresses (AWS does), so we can't create an authoritative reverse lookup for them. There are lots of DDOS protection services out there for web sites, but for reasons I hope are obvious we can't make recommendations. Oh ... and also, we're mostly stopping using 'lindenlab.com' for the backend service domains (it's mostly being replaced by 'secondlife.io' or some subdomain of that).
  10. it would be easier if any questions or updates were all in that one thread in any event, thanks for your testing. I don't know whether or not this build has all the latest region crossing updates
  11. Unfortunately implementing your suggestion would not be nearly as easy as you might think and would in the end not provide a strong assurance. This is why we're making a special effort to publicize these changes well before they start appearing on the main grid. We are well aware that making changes to LSL behavior that are potentially not backwards-compatible has the potential to break content, so we're very careful about doing so. In particular, changes that require scripts to be updated are especially problematic since they're so often relied upon by people who can't update the script.
  12. Using IP addresses and DNS names as an authentication method isn't a good idea even when it appears to work. A much better approach would be to put a secret string in your script and send a hash of that secret and the message along with the message. The server knows the secret, so it can verify that the message is authentic. This verifies not only that it's coming from some simulator, but that the source knows the secret.
  13. The first testing region for these HTTP changes is available now: Cloud Sandbox 4 on the Aditi (beta) grid If you have difficulty logging in to that grid, it may be because your account has not been copied there; submit a Support request to get that fixed.
  14. A few of the features of LSL HTTP usage will be changing slightly as a part of the migration to using cloud hosted simulators. Our hope is that these changes will not cause any problems, but hope and testing are two different things, so... If you are the creator of LSL scripts that use any of the features discussed below, or you use scripts that rely on external HTTP services that were created by someone else, you should test them as soon as possible and report any problems in Jira. As sandboxes where you can test with these changes are deployed, we will post notices in this thread.
×
×
  • Create New...