I'm mostly a python guy, who only dabbles in javascript when I can't avoid it :-)
I've got a django-based tool (https://tools.wmflabs.org/spi-tools-dev/spi/ https://tools.wmflabs.org/spi-tools-dev/spi/) which uses selectize.js. For simple cases, everything works fine. But, if I click on the drop-down, delete the contents, type in a new value, and submit the form (Sock Info button), the submitted form data has case_name blank.
Is there anybody here who is familiar with javascript and/or selectize.js who would be willing to point me in the right direction?
Hi,
I clicked on the link, but most if not all of the CSS and Javascript didn't load because of cross site scripting failures. Maybe you should start there?
Cheers, -Travis
On Mon, Jun 22, 2020 at 7:01 PM Roy Smith roy@panix.com wrote:
I'm mostly a python guy, who only dabbles in javascript when I can't avoid it :-)
I've got a django-based tool (https://tools.wmflabs.org/spi-tools-dev/spi/) which uses selectize.js. For simple cases, everything works fine. But, if I click on the drop-down, delete the contents, type in a new value, and submit the form (Sock Info button), the submitted form data has case_name blank.
Is there anybody here who is familiar with javascript and/or selectize.js who would be willing to point me in the right direction? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
most if not all of the CSS and Javascript didn't load because of cross
site scripting failures
The Content Security Policy violations are report-only, if that's what you're referring to. Popper, Bootstrap, jQuery and Selectize are all available via https://cdnjs.toolforge.org/ which will get around the CSP directive. For fonts you could try https://fontcdn.toolforge.org/
~ MA
On Mon, Jun 22, 2020 at 11:30 PM Travis Briggs audiodude@gmail.com wrote:
Hi,
I clicked on the link, but most if not all of the CSS and Javascript didn't load because of cross site scripting failures. Maybe you should start there?
Cheers, -Travis
On Mon, Jun 22, 2020 at 7:01 PM Roy Smith roy@panix.com wrote:
I'm mostly a python guy, who only dabbles in javascript when I can't avoid it :-)
I've got a django-based tool ( https://tools.wmflabs.org/spi-tools-dev/spi/) which uses selectize.js. For simple cases, everything works fine. But, if I click on the drop-down, delete the contents, type in a new value, and submit the form (Sock Info button), the submitted form data has case_name blank.
Is there anybody here who is familiar with javascript and/or selectize.js who would be willing to point me in the right direction? _______________________________________________ Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
Thank you for reminding me that fixing this has been on my list https://github.com/roysmith/spi-tools/issues/4 for a while. My CSP-fu is weak. As I understand it, all I need do is:
<!-- Bootstrap CSS --> <link rel="stylesheet" - href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" - integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" - crossorigin="anonymous"> + href="https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css..." + integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T">
and similar changes for the other linked-to resources. Two specific questions: The integrity token is the same, no matter which mirror I get it from? I can drop the crossorigin attribute since I'm not doing CORS any more?
On Jun 23, 2020, at 3:06 PM, MusikAnimal musikanimal@gmail.com wrote:
The Content Security Policy violations are report-only, if that's what you're referring to. Popper, Bootstrap, jQuery and Selectize are all available via https://cdnjs.toolforge.org/ https://cdnjs.toolforge.org/ which will get around the CSP directive. For fonts you could try https://fontcdn.toolforge.org/ https://fontcdn.toolforge.org/
~ MA
Oh, this is unexpected. When I do the change diffed below, I get:
Subresource Integrity: The resource 'https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css...' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
It looks like I need to drop the integrity attribute as well. Or, is there value in keeping both the integrity and crossorigin="anonymous", since (I'm assuming) that will provide some protection against the file being unexpectedly replaced with something else?
On Jun 24, 2020, at 9:41 AM, Roy Smith roy@panix.com wrote:
Thank you for reminding me that fixing this has been on my list https://github.com/roysmith/spi-tools/issues/4 for a while. My CSP-fu is weak. As I understand it, all I need do is:
<!-- Bootstrap CSS -->
<link rel="stylesheet" - href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css <https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css>" - integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" - crossorigin="anonymous"> + href="https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css <https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css>" + integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T">
and similar changes for the other linked-to resources. Two specific questions: The integrity token is the same, no matter which mirror I get it from? I can drop the crossorigin attribute since I'm not doing CORS any more?
On Jun 23, 2020, at 3:06 PM, MusikAnimal <musikanimal@gmail.com mailto:musikanimal@gmail.com> wrote:
The Content Security Policy violations are report-only, if that's what you're referring to. Popper, Bootstrap, jQuery and Selectize are all available via https://cdnjs.toolforge.org/ https://cdnjs.toolforge.org/ which will get around the CSP directive. For fonts you could try https://fontcdn.toolforge.org/ https://fontcdn.toolforge.org/
~ MA
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
I wouldn't think you'd need any additional attributes. Just something like:
<link rel="stylesheet" type="text/css" href=" https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css ">
This is how I do it in my tools.
~ MA
On Wed, Jun 24, 2020 at 10:15 AM Roy Smith roy@panix.com wrote:
Oh, this is unexpected. When I do the change diffed below, I get:
Subresource Integrity: The resource ' https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css...' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
It looks like I need to drop the integrity attribute as well. Or, is there value in keeping both the integrity and crossorigin="anonymous", since (I'm assuming) that will provide some protection against the file being unexpectedly replaced with something else?
On Jun 24, 2020, at 9:41 AM, Roy Smith roy@panix.com wrote:
Thank you for reminding me that fixing this has been on my list https://github.com/roysmith/spi-tools/issues/4 for a while. My CSP-fu is weak. As I understand it, all I need do is:
<!-- Bootstrap CSS -->
<link rel="stylesheet" - href=" https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" - integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" - crossorigin="anonymous"> + href=" https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css " + integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T">
and similar changes for the other linked-to resources. Two specific questions:
- The integrity token is the same, no matter which mirror I get it
from?
- I can drop the crossorigin attribute since I'm not doing CORS any
more?
On Jun 23, 2020, at 3:06 PM, MusikAnimal musikanimal@gmail.com wrote:
The Content Security Policy violations are report-only, if that's what you're referring to. Popper, Bootstrap, jQuery and Selectize are all available via https://cdnjs.toolforge.org/ which will get around the CSP directive. For fonts you could try https://fontcdn.toolforge.org/
~ MA
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
Honestly, I don't see any downsides to just keeping the attributes. Integrity validation is a valid defense and if it's blocked for some reason that should be fixed on our side.
YiFei Zhu
On Wed, Jun 24, 2020, 10:11 MusikAnimal musikanimal@gmail.com wrote:
I wouldn't think you'd need any additional attributes. Just something like:
<link rel="stylesheet" type="text/css" href=" https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css ">
This is how I do it in my tools.
~ MA
On Wed, Jun 24, 2020 at 10:15 AM Roy Smith roy@panix.com wrote:
Oh, this is unexpected. When I do the change diffed below, I get:
Subresource Integrity: The resource ' https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css...' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
It looks like I need to drop the integrity attribute as well. Or, is there value in keeping both the integrity and crossorigin="anonymous", since (I'm assuming) that will provide some protection against the file being unexpectedly replaced with something else?
On Jun 24, 2020, at 9:41 AM, Roy Smith roy@panix.com wrote:
Thank you for reminding me that fixing this has been on my list https://github.com/roysmith/spi-tools/issues/4 for a while. My CSP-fu is weak. As I understand it, all I need do is:
<!-- Bootstrap CSS -->
<link rel="stylesheet" - href=" https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" - integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" - crossorigin="anonymous"> + href=" https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css/bootstrap.min.css " + integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T">
and similar changes for the other linked-to resources. Two specific questions:
- The integrity token is the same, no matter which mirror I get it
from?
- I can drop the crossorigin attribute since I'm not doing CORS any
more?
On Jun 23, 2020, at 3:06 PM, MusikAnimal musikanimal@gmail.com wrote:
The Content Security Policy violations are report-only, if that's what you're referring to. Popper, Bootstrap, jQuery and Selectize are all available via https://cdnjs.toolforge.org/ which will get around the CSP directive. For fonts you could try https://fontcdn.toolforge.org/
~ MA
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud
On Wed, Jun 24, 2020 at 8:15 AM Roy Smith roy@panix.com wrote:
Oh, this is unexpected. When I do the change diffed below, I get:
Subresource Integrity: The resource 'https://tools-static.wmflabs.org/cdnjs/ajax/libs/twitter-bootstrap/4.3.1/css...' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
It looks like I need to drop the integrity attribute as well. Or, is there value in keeping both the integrity and crossorigin="anonymous", since (I'm assuming) that will provide some protection against the file being unexpectedly replaced with something else?
The integrity hash is a nice thing to have for defense in depth against some MITM attack against the proxy or malicious content injection at the upstream source. I would guess that the hash change is due to some non-repeatable build issue in the css compression used by the two different CDN archives. You can find the published hash for the CDNJS file using the upstream interface at https://cdnjs.com/libraries/twitter-bootstrap. Alternately, you can download the file through the proxy, review it to convince yourself that the file is attack free, and compute the sha256 or sha384 hash locally.
I would also recommend keeping the crossorigin="anonymous" attribute. The Cloud Services proxy is privacy respecting, but again this is a defense in depth protection against any possible rogue activity at that proxy.
Bryan
OK, I got this solved. Turns out I had a bug in my django template inheritance, which was causing selectize to load before jquery.
In an odd sort of way, the issue with the Content Security Policy violations turned out to be important. I knew it was a problem, but blew off doing anything about it because it was just warnings. It turns out I was getting a javascript console error about $ not being defined, but it was lost in all the noise from all the CSP warnings. Once I cleared those up, all that was left was the $ not defined error and it became obvious what was going on.
I think there's like some basic software engineering lesson in there :-)
On Jun 22, 2020, at 10:01 PM, Roy Smith roy@panix.com wrote:
I'm mostly a python guy, who only dabbles in javascript when I can't avoid it :-)
I've got a django-based tool (https://tools.wmflabs.org/spi-tools-dev/spi/ https://tools.wmflabs.org/spi-tools-dev/spi/) which uses selectize.js. For simple cases, everything works fine. But, if I click on the drop-down, delete the contents, type in a new value, and submit the form (Sock Info button), the submitted form data has case_name blank.
Is there anybody here who is familiar with javascript and/or selectize.js who would be willing to point me in the right direction?
Unless something has changed, Wmflabs policy requires that we only use Wikimedia CDNs. Other CDNs use cookies to track a user's actions, which violates the privacy policy.
Magog
On Wed, Jun 24, 2020 at 3:41 PM Roy Smith roy@panix.com wrote:
OK, I got this solved. Turns out I had a bug in my django template inheritance, which was causing selectize to load before jquery.
In an odd sort of way, the issue with the Content Security Policy violations turned out to be important. I knew it was a problem, but blew off doing anything about it because it was just warnings. It turns out I was getting a javascript console error about $ not being defined, but it was lost in all the noise from all the CSP warnings. Once I cleared those up, all that was left was the $ not defined error and it became obvious what was going on.
I think there's like some basic software engineering lesson in there :-)
On Jun 22, 2020, at 10:01 PM, Roy Smith roy@panix.com wrote:
I'm mostly a python guy, who only dabbles in javascript when I can't avoid it :-)
I've got a django-based tool (https://tools.wmflabs.org/spi-tools-dev/spi/) which uses selectize.js. For simple cases, everything works fine. But, if I click on the drop-down, delete the contents, type in a new value, and submit the form (Sock Info button), the submitted form data has case_name blank.
Is there anybody here who is familiar with javascript and/or selectize.js who would be willing to point me in the right direction?
Wikimedia Cloud Services mailing list Cloud@lists.wikimedia.org (formerly labs-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/cloud