On Wed, Aug 12, 2020 at 8:47 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Konstantin, > > On 8/12/20 10:02, Konstantin Kolinko wrote: > > вт, 28 июл. 2020 г. в 16:55, Christopher Schultz > > <ch...@christopherschultz.net>: > >> > >> All, > >> > >> I was looking at this PR[1] and wondering why we have huge swaths > >> of CSS and HTML in a Java source file, instead of using e.g. JSP > >> or some other content-generation framework. > > > > I remember that I once read some praise for being able to use the > > Manager web application when there is no Jasper and no JSP > > compiler available. It was more than 5 years ago and I do not > > remember the details - maybe it was some small system with limited > > hardware. > > Agreed. > > > The Manager app does use JSPs nowadays, not for some unimportant > > pages: listing of sessions and listing attributes of a session. > > Okay. Are you suggesting then that JSP can/should be required for > Manager usage? Or maybe just for certain functions? > > >> I know, I hate JSP, too, but having large blocks of HTML and CSS > >> in Java strings is just ... awful. > >> > >> Also, is there a particular reason we are using embedded CSS in > >> the pages instead of an external CSS file? > > > > Originally it was rather small. It grows with time. > > Okay. I think it's time to separate. > > > A separate file needs a license header, so the size will grow. > > I'm okay with that. > > >> Ultimately, it would be a good idea to move all CSS and even > >> styles into a separate CSS file so we can tighten-up the Content > >> Security Policy on the manager app. This can help prevent attacks > >> if there happens to be some kind of XSS vulnerability hiding in > >> there somewhere. > > > > I do not get how having a separate file [matters] with Content > > Security Policy. > > Having separate CSS allows a site to allow external styles but > prohibit in-page styles. The allow-token for CSP for inline styles is > "unsafe-inline". > > The reason this is a security issue is for XSS attacks. If an XSS > attack is in progress, the script may attempt to modify the page's > styles to manipulate the user. For example, hiding some important data > or warning message. XSS would have more difficulty spoofing an > externally-loaded CSS file. > > I don't think we have any js in the Manager, but external js is better > as well, as the page is therefore prohibited from running any js code > appearing in the page: all scripts must be external. > I don't see any scripts either. Why not add a CSP and set script to 'none'? I can add that if no one objects. > > Speaking of which, we should look at defining a CSP for the Manager > application. > > >> Any objections to evicting the CSS to begin with? > > > > No objection, if you want it. > I have extracted the CSS from the Java code on master [2]. I plan to port that to 9.0.x and 8.5.x. Feedback welcomed. I also replaced the old GIF logo with an SVG image from the main page as it looks more modern and crisp, especially on high resolution screens. I personally don't think that a few KBs make a difference with the code size, but if it is a concern then we can remove the multiple copies of the logos (Tomcat and ASF) for example from the different web applications, and copy them over at build time. So we will have a slightly smaller codebase at the expense of a bit more complicated build process. Best, Igal [2] https://github.com/apache/tomcat/commit/9c5d2e3b633fdb651bc9f11db4aac97ad3ad4df2 > > > > We already have image files. Thus, why not? > > Sine you mentioned it, how to we "license" image files? > > >> [1] https://github.com/apache/tomcat/pull/327 > > > > An odd PR. I see that it makes some visual changes, but there is > > no description nor discussion what the actual changes are. > > I care less about this specific PR and more about cleaning everything up > . > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl80Dx8ACgkQHPApP6U8 > pFhSSg/9EQQpZ6WLOeMA7o41UJ3o/X49Xu5h7mliFhIQ6xNkoqW6sWkOHy0LURqU > 4S+WaPQzNsXqU8gREcKcU1OPNFnh2i3hGaD6mc/Tr5PMg82qBDwozxM9L6pcKo/N > d30RiJ5MeenrLZ/chbC8Kq4pqBbNtChQWmVH4Dp469DIAwhE3A6T7pwiB1bB72Tz > DxW/1PTAZENvkchkhll/UyEd+pJV9rq1CrrR8LRpqkEkZqu50vKFhE7XWIn4AkZf > OXhtI+SLh/1cxeVMfVjq7JyoslMHiZ7d+55wybvdRWZLns+OMeOTjxW6nzAaB8nN > SYEs/x/+HOV2x91btCpurttGFNzjdU3VqnM/Xk0mThVoxP0CktOSePGlUKd8gqi1 > Jed/RxeaKSUSjrghhCJLnvsNhqUfXMy35eATWdJ+YPhIyxM1aotBPZN9zZRKh2zp > IPM/VvpFWJsIiIzbzhLfQfRNK9UpLaTL96s+V/5opoIHpPVpW+T8uSVrFpysfErE > fZVC027SgEDzDjtBvPhRN4E8kK4rUKiAOyJJX/M3q7iJKZj1zy5NOo3RQZ7WAqIv > Qx8mAwIi+/cNaQotbCuTkTpObzSHetR6OF9RQDZG/zAMI+W5/9eVTrZucto4yCB8 > 9fMGf2YTrqnF4qF5JMAKzRH+kucGyZx4q8aX9SY+RTl5GuGcGKI= > =xI8S > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
