You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Propes, Barry L " <ba...@citi.com> on 2011/01/06 19:16:49 UTC
Security container behavior toward .js file reference
Hi Tomcat users,
I'm experiencing (what I think is) a weird problem regarding a javascript reference file when accessed across the security container.
For several years, I've had some manual breadcrumb links written in each separate JSP file. So I thought I'd more easily consolidate into a .js file and just reference the link in each page that way.
e.g. <script language="javascript" src="myapp_breadcrumb.js"></script>
It now prompts me if I want to save it (in IE) or in Firefox tries to display the javascript contents.
To me this is odd because I already have a .js reference that's been in there for several years, and the container never balked at that.
I'm not altogether positive, but perhaps it's the fact that I used some document.write methods to write them into the file? Although I wouldn't think that would really be any different, but this is puzzling behavior to me.
Anyway, if anyone knows why this might be happening, I welcome any feedback.
If you're thinking this isn't Tomcat-related, it's HTML/JavaScript related, well, it works fine on the non-protected area from the container.
It's when logging on that it suddenly gets flagged. Another weird issue, to me, is that initially in Firefox it tried to display the .js file reference in the browser.
But if I just type over the .js file in the web browser and key in the intended page, sans URL parameters of any kind, it gets there fine and displays the content as intended.
Thanks,
Barry
RE: Security container behavior toward .js file reference
Posted by "Propes, Barry L " <ba...@citi.com>.
Hi Chris,
I'll reply on each one, but the long story short, I think I found the reason -- I'd also amended these in both the login.html and login_error.html files.
I'd manually had a block of JavaScript code in separate files, that had a supplemental menu bar .js include that worked in conjunction with the block of code.
However, when I changed that block of code to an additional .js reference, it balked at that.
E.g.
Block -
var approvedlogo = 'company';
var pagetitle = 'My App';
breadcrumb = new Array();
breadcrumb[0] = '<a href="http://coservicingmachine.net/dir1/subdir/menu_home.htm" style="text-decoration:none; color:#000066">Operations Manuals</a><b> </b>'
breadcrumb[1] = '<a href="http://secondary.colocator.com/" style="text-decoration:none; color:#000066">Tertiary Div</a><b> < </b>'
breadcrumb[2] = '<a href="http://coservicingmachine.net/dir1/subdir/finan_home.htm" style="text-decoration:none; color:#000066">Financial Manuals Home</a><b> < </b>'
This was typed in the various pages, but when I crammed this into a separate ,js file, "breadcrumb.js" and referenced it, it balked in the two login HTML files in the protected area. That's what I meant "across the security container," though likely worded poorly.
If I leave this block of code in the two login HTML files, it will work fine. I can put them in any and all JSPs I choose to.
Sorry for any confusion.
Thanks, Chris!
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Thursday, January 06, 2011 3:32 PM
To: Tomcat Users List
Subject: Re: Security container behavior toward .js file reference
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Barry,
On 1/6/2011 1:16 PM, Propes, Barry L wrote:
> I'm experiencing (what I think is) a weird problem regarding a
> javascript reference file when accessed across the security container.
What do you mean "across the security container"? John Lennon really got weird toward the end, huh?
> For several years, I've had some manual breadcrumb links written in
> each separate JSP file. So I thought I'd more easily consolidate into
> a .js file and just reference the link in each page that way.
So you went from server-side dynamic breadcrumb-trails to client-side ones built using Javascript? Yikes! Might I recommend using a JSP include?
> e.g. <script language="javascript" src="myapp_breadcrumb.js"></script>
Try: <script type="text/javascript" src="myapp_breadcrumb.js"></script>
In HTML4, "language" is deprecated because it never had any well-defined values. From http://www.w3.org/TR/html4/interact/scripts.html:
"
language = cdata [CI]
Deprecated. This attribute specifies the scripting language of the contents of this element. Its value is an identifier for the language, but since these identifiers are not standard, this attribute has been deprecated in favor of type.
"
> It now prompts me if I want to save it (in IE) or in Firefox tries to display the javascript contents.
No content type = undefined behavior, though the server should have been serving .js files as text/javascript. Check with a protocol sniffer to see if that happened. You probably have comments at the top of the file which make MSIE do foolish things because it always tries to guess content-type from content.
> To me this is odd because I already have a .js reference that's been
> in there for several years, and the container never balked at that.
What does that reference look like? The container is unlikely to balk at it since it never considers is. In these cases, the /clients/ are balking.
> I'm not altogether positive, but perhaps it's the fact that I used
> some document.write methods to write them into the file? Although I
> wouldn't think that would really be any different, but this is
> puzzling behavior to me.
Why are you using document.write to add <script> elements to the file?
Maybe I just don't understand "Web 2.0" :)
> Anyway, if anyone knows why this might be happening, I welcome any feedback.
>
> If you're thinking this isn't Tomcat-related, it's HTML/JavaScript related, well, it works fine on the non-protected area from the container.
What happens if you use MSIE and actually download the file. What contents do you get? Do you get an error page in .js clothing?
> It's when logging on that it suddenly gets flagged. Another weird
> issue, to me, is that initially in Firefox it tried to display the .js
> file reference in the browser.
What does it mean to display a .js file reference in the browser?
> But if I just type over the .js file in the web browser and key in the
> intended page, sans URL parameters of any kind, it gets there fine and
> displays the content as intended.
Are you usually using parameters?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0mNLQACgkQ9CaO5/Lv0PAy/ACcDLDzKyKx8Fr4YNpNkY9RnEpL
v+wAnRjHNuVGFrZYsjQcJqOS8fj3Ak0p
=kf2J
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Security container behavior toward .js file reference
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Barry,
On 1/6/2011 1:16 PM, Propes, Barry L wrote:
> I'm experiencing (what I think is) a weird problem regarding a
> javascript reference file when accessed across the security
> container.
What do you mean "across the security container"? John Lennon really got
weird toward the end, huh?
> For several years, I've had some manual breadcrumb links written in
> each separate JSP file. So I thought I'd more easily consolidate into
> a .js file and just reference the link in each page that way.
So you went from server-side dynamic breadcrumb-trails to client-side
ones built using Javascript? Yikes! Might I recommend using a JSP include?
> e.g. <script language="javascript" src="myapp_breadcrumb.js"></script>
Try: <script type="text/javascript" src="myapp_breadcrumb.js"></script>
In HTML4, "language" is deprecated because it never had any well-defined
values. From http://www.w3.org/TR/html4/interact/scripts.html:
"
language = cdata [CI]
Deprecated. This attribute specifies the scripting language of the
contents of this element. Its value is an identifier for the language,
but since these identifiers are not standard, this attribute has been
deprecated in favor of type.
"
> It now prompts me if I want to save it (in IE) or in Firefox tries to display the javascript contents.
No content type = undefined behavior, though the server should have been
serving .js files as text/javascript. Check with a protocol sniffer to
see if that happened. You probably have comments at the top of the file
which make MSIE do foolish things because it always tries to guess
content-type from content.
> To me this is odd because I already have a .js reference that's been
> in there for several years, and the container never balked at that.
What does that reference look like? The container is unlikely to balk at
it since it never considers is. In these cases, the /clients/ are balking.
> I'm not altogether positive, but perhaps it's the fact that I used
> some document.write methods to write them into the file? Although I
> wouldn't think that would really be any different, but this is puzzling
> behavior to me.
Why are you using document.write to add <script> elements to the file?
Maybe I just don't understand "Web 2.0" :)
> Anyway, if anyone knows why this might be happening, I welcome any feedback.
>
> If you're thinking this isn't Tomcat-related, it's HTML/JavaScript related, well, it works fine on the non-protected area from the container.
What happens if you use MSIE and actually download the file. What
contents do you get? Do you get an error page in .js clothing?
> It's when logging on that it suddenly gets flagged. Another weird
> issue, to me, is that initially in Firefox it tried to display the
> .js file reference in the browser.
What does it mean to display a .js file reference in the browser?
> But if I just type over the .js file in the web browser and key in
> the intended page, sans URL parameters of any kind, it gets there
> fine and displays the content as intended.
Are you usually using parameters?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0mNLQACgkQ9CaO5/Lv0PAy/ACcDLDzKyKx8Fr4YNpNkY9RnEpL
v+wAnRjHNuVGFrZYsjQcJqOS8fj3Ak0p
=kf2J
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org