Pages created via the additional contents tool should have the ability to contain their own jQuery. Currently, jQuery to be used on a custom page must be put into one of the UserJS system preferences. Those system preferences tend to include a lot of code saved as one long block. It'd be great to be able to keep custom page code separate. For contrast, one can just put CSS straight into a page and have it work correctly.
Inline Javascript and CSS will be a problem for the eventual adoption of Content-Security-Policy. If it were to be done, I think it would need to be stored in separate database columns, so that a CSP nonce could be added to it in the templates.
(In reply to David Cook from comment #1) > Inline Javascript and CSS will be a problem for the eventual adoption of > Content-Security-Policy. > > If it were to be done, I think it would need to be stored in separate > database columns, so that a CSP nonce could be added to it in the templates. Then this seems like it would be more trouble then it is worth when we already have a good place for the JS, the USerJS's. I do sympathize with Andrew's problem. If you have a custom page that displays on the OPAC and staff interface you'll need to duplicate JS and put in both OPACJS and IntranetUserJS.
(In reply to Lucas Gass from comment #2) > Then this seems like it would be more trouble then it is worth when we > already have a good place for the JS, the USerJS's. > > I do sympathize with Andrew's problem. If you have a custom page that > displays on the OPAC and staff interface you'll need to duplicate JS and put > in both OPACJS and IntranetUserJS. That would be an annoying problem. Overall, I'm unhappy with how we're doing HTML/CSS/JS content management in Koha. It is tough having Koha be all things to all people, and trying to maintain the balance of security and convenience...
Created attachment 164691 [details] [review] Bug 36152: Tidy
This would be a great addition.
(In reply to George Williams (NEKLS) from comment #5) > This would be a great addition. It would be more convenient but it would create an even wider security problem.
> It would be more convenient but it would create an even wider security > problem. I definitely agree, David. We should be putting JS in less places, not more. Security needs to take precedence. It is only mildly inconvenient to have to add JS to the UserJS sys prefs. I am inclined to mark this as RESOLVED - WONT FIX.
(In reply to Lucas Gass from comment #7) > > It would be more convenient but it would create an even wider security > > problem. > > I definitely agree, David. We should be putting JS in less places, not more. > Security needs to take precedence. It is only mildly inconvenient to have to > add JS to the UserJS sys prefs. > > I am inclined to mark this as RESOLVED - WONT FIX. Agreed. @Andrew can you speak more to your original intention? I agree that *UserJS can get very long and be difficult to maintain, so I can understand wanting to break it up into more specific chunks. Personally, I'd love to eliminate the *UserJS preferences, but I don't think anyone will ever agree with me on that one, so I think we should protect them with a higher level of permission, which would involve a new UI. One thought I have is a UI that lets you create blocks of JS and assign them to a name, and then perhaps use something like [% Asset.UserJS('this_js_name') %] in the HTML for that page could inject the JS into the page. Another thought it just a UI that lets you create separate blocks of JS that get merged into the same <script></script> element, but helps you manage them separately. (At this point, technically speaking, you could create page-specific Javascript, upload it via the "Uploads" tool and just include it on the pages you want. But in the future, we will be preventing <script> tags in many of the HTML areas, so perhaps not wise to use this workaround.)
Overall, I'd love to hear all the use cases I can for Javascript in Koha, so that I can design something that works for everyone. -- Locally, I've been thinking of disabling the *UserJS preferences, and moving the code from them into file system files. I'm still thinking about how to inject the '<script src=""></script>' tags though. I'd want it to be configuration driven. Since I work for a vendor, I can do this all on the file system. It would mean customers would need to request Javascript changes, which would increase friction, but it would increase system security (and stability). Alternatively, I've thought about keeping OpacUserJS, but restricting IntranetUserJS, although technically someone could exploit OpacUserJS to take over an admin account and then gain access to the staff interface by changing their password anyway (if they're not using MFA/SSO). More thinking to do...
(In reply to David Cook from comment #9) > Overall, I'd love to hear all the use cases I can for Javascript in Koha, so > that I can design something that works for everyone. We do have the use case that for some services, we need to include JS files that are on our server, but there is no nice way to do that right now. We end up putting something like: </script><script.... /><script> into the UserJS file in order to be able to do that. Sometimes libraries also want to use something like Matomo or Webtrack and we need to integrate that. I think something strictly server side would indeed create a lot of friction and extra work. Something more protected seems a better way.
(In reply to Katrin Fischer from comment #10) > (In reply to David Cook from comment #9) > > Overall, I'd love to hear all the use cases I can for Javascript in Koha, so > > that I can design something that works for everyone. > > We do have the use case that for some services, we need to include JS files > that are on our server, but there is no nice way to do that right now. We > end up putting something like: </script><script.... /><script> into the > UserJS file in order to be able to do that. Why not just put the script tags in opacheader or opaccredits? > Sometimes libraries also want to use something like Matomo or Webtrack and > we need to integrate that. > > I think something strictly server side would indeed create a lot of friction > and extra work. Something more protected seems a better way. Yeah, the most secure computer is the one in a room with no network connection and no door, but then no one can use it hehe. I'm going to think more about this post-Kohacon (or maybe even at the hackfest...)
I think we have that as well (opaccredits, opacheader), but with the new HTML customizations is a bit harder to edit and not get it destroyed by accident. Also sometimes there is additional JS bits needed, so that keeps it all in one spot.
(In reply to Katrin Fischer from comment #12) > I think we have that as well (opaccredits, opacheader), but with the new > HTML customizations is a bit harder to edit and not get it destroyed by > accident. Also sometimes there is additional JS bits needed, so that keeps > it all in one spot. Oh that's interesting!