Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-216465] Viewer web widgets not HTTPS ready #3833

Open
2 tasks
sl-service-account opened this issue Jun 18, 2018 · 6 comments
Open
2 tasks

[BUG-216465] Viewer web widgets not HTTPS ready #3833

sl-service-account opened this issue Jun 18, 2018 · 6 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 18, 2018 •
edited by sl-issues-importer bot

How would you like the feature to work?

Hi,

I refer to http://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Web_Widgets

It would be nice if there was a version of this javascript code that could be embedded in pages that will be served over HTTPS sessions. Currently, this is impossible with the current widget code as the javascript code references assets from hosts that are HTTP enabled only (causing browsers not to load the script as it is considered unsafe due to 'mixed content').

I had a go at editing the javascript code in sl.widgets.js and changing the baseURL variable to use HTTPS instead of HTTP however it seems this is nowhere near enough work to make it play nice (see attached screenshot).

Why is this feature important to you? How would it benefit the community?

The community would benefit because it means they can use your widget code in web pages that are served over a HTTPS session.

Attachments

Links

Duplicates

Related

Original Jira Fields
Field Value
Issue BUG-216465
Summary Viewer web widgets not HTTPS ready
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter mygoditsfullofstars (mygoditsfullofstars)
Created at 2018-06-18T05:52:24Z
Updated at 2021-09-02T17:32:23Z 
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2018-06-19T04:26:27.760-0500',
  'How would you like the feature to work?': "Hi,\r\n\r\nI refer to http://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Web_Widgets\r\n\r\nIt would be nice if there was a version of this javascript code that could be embedded in pages that will be served over HTTPS sessions. Currently, this is impossible with the current widget code  as the javascript code references assets from hosts that are HTTP enabled only (causing browsers not to load the script as it is considered unsafe due to 'mixed content').\r\n\r\nI had a go at editing the javascript code in sl.widgets.js and changing the baseURL variable to use HTTPS instead of HTTP however it seems this is nowhere near enough work to make it play nice (see attached screenshot).\r\n",
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'The community would benefit because it means they can use your widget code in web pages that are served over a HTTPS session.\r\n',
}
@sl-service-account
Copy link
Author

Chaser Zaks commented at 2018-06-19T09:26:28Z

+1 support
All APIs should utilize the ambiguous protocol handler(EG: instead of http://example.com/endpoint or https://example.com/endpoint, it should use //example.com/endpoint). Additionally the ws.world-ng.agni.lindenlab.com server doesn't seem to have a valid certificate(Possibly internal certificate?) so that would also need to be fixed.

@sl-service-account
Copy link
Author

Kyle Linden commented at 2018-06-20T18:04:16Z

Importing for future consideration.

@sl-service-account
Copy link
Author

panterapolnocy commented at 2020-07-25T14:18:04Z, updated at 2020-07-25T14:48:02Z

That is indeed still an issue. I've tried to upgrade Firestorm splash page to use HTTPS and to cheat a little with forcing all data from widgets to go via that protocol, but got stopped with the SSL_ERROR_BAD_CERT_DOMAIN certificate error in Firefox and ERR_CERT_COMMON_NAME_INVALID in Chrome during testing on ws.world-ng.agni.lindenlab.com domain. All the rest loaded nicely, but this one has just a bad certificate ("requested domain name does not match the server's certificate", with strict transport security and public key pinning set to false). Thus, we're still forced to serve splash over HTTP.

image-2020-07-25-16-14-20-942.png

I am aware that Oz said "coming soon" here https://www.youtube.com/watch?v=D0-uiyxGaUw&feature=youtu.be&t=3m26s but 2 years is not really "soon" any more. ;) Unless... would this be the part of Uplift as well?

@sl-service-account
Copy link
Author

panterapolnocy commented at 2020-07-25T18:20:46Z, updated at 2020-07-26T00:04:17Z

Bonus information that can be provided is the fact, that none of the resources coming from Lab's widgets servers are compressed (GZIP / Deflate). Sure, they are cached, yet still it's a clear waste of bandwidth and network.

 

image-2020-07-25-20-20-14-646.png

 

Minification could also be useful.

 

image-2020-07-25-20-23-28-182.png

@sl-service-account
Copy link
Author

mygoditsfullofstars commented at 2020-07-26T04:25:31Z, updated at 2020-07-26T04:26:06Z

@pantera

I already reported the issue with non compressed content on another Jira ticket, see: https://jira.secondlife.com/browse/BUG-228229

If you have just tested this now, I guess we can take it to mean that nothing has been done yet to address the issue... :(

 

@sl-service-account
Copy link
Author

panterapolnocy commented at 2021-09-02T17:32:24Z

Widgets in the first three accordions seems to work now, under https; Thank you.

https://phoenixviewer.com/app/loginV3/?lang=en

 

This was referenced Feb 14, 2024
Closed
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account