Re: Mozilla showing JSP source code
Hello Guy, If you have the return in the right place, you shouldn't be seeing the problem. Since the return is in an include, is it possible that the jsp including the file didn't rebuild itself? I have had problems where I needed to stop tomcat, delete the context directory from work directory where the compiled jsp's are kept by tomcat, then restart tomcat and let it recompile everything. Depending on your configuration, tomcat might not rebuild jsp's when included files are modified. Of course you might want to check ahead of time and see if the compiled version has the return in the right place. Let me know if there is anything else I can do to help. Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Guy Rouillier [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:44 AM Subject: RE: Mozilla showing JSP source code Sean Utt wrote: Hi, I used to see this when doing a response.sendRedirect() without following it with a return(), but didn't see jsp source, just html source. I did have a problem with mod_jk showing .jsp source when the URI contained a // in the path like http://dom.ain/context//file.jsp, but that sounds like a different problem and an upgrade of mod_jk fixed that. Sean, thanks for the reply. Now that you mention it, I am indeed seeing HTML source, not JSP source. We do a *pretty* good job of putting returns after our redirects, though I find an occasional missing return. On all the pages I'm investigating, sendRedirect is followed by a return. And of course there is always the problem of Tomcat not *allowing* you to put a return if the sendRedirect is the last statement on the page; you get a code not reachable on the curly brace that follows it grr. Were you able to resolve the showing of the HTML source? Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Guy Rouillier [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 5:36 PM To: Tomcat Users List Subject: Mozilla showing JSP source code [snip] (4) The most reliable way to see this fail is via a redirect. This happens most frequently on the secure half of our website (https). On those pages, we have an authentication header at the top of each page: %@ include file=/includes/authenheader.jspf % Inside this file, we check some session variables, and if they don't have the right set of values (or those values don't exist) we response.sendRedirect() to a login page. During this redirect, I *always* see the source for the login page - the login page has not come up cleanly one time. This page is very small, and neither the buffer or timeout changes help. If anyone has any ideas on how to address this problem, I'm willing to try anything. I really am out of ideas and don't know where to go next. Thanks for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mozilla showing JSP source code
Hi,
I used to see this when doing a response.sendRedirect() without following it
with a return(), but didn't see jsp source, just html source. I did have a
problem with mod_jk showing .jsp source when the URI contained a // in the
path like http://dom.ain/context//file.jsp, but that sounds like a different
problem and an upgrade of mod_jk fixed that.
The redirect without return was a common problem in dreamweaver ultradev 4.
response.sendRedirect() does not terminate execution of the servlet/jsp (nor
should it), it just adds header content to the output. I.E. is being 'nice'
by painting over the html of the page that sent the redirect with the html
of the redirected page, but netscape/mozilla leaves the html from the
redirecting page in the browser. A more serious issue is that if you are
using response.sendRedirect() to send an unauthorized user to a login page,
you are sending them the content you were trying to protect, and then
telling them they need to log in to see it. Not at all secure.
Though this is an overly simplistic analogy, think of a servlet/jsp as a
dynamically loaded function being called by tomcat. This is why you can't
call system.exit() in a servlet without terminating tomcat itself. Unless
you tell the servlet to cease processing, it will happily continue doing
what it does best -- outputting html.
bottom line:
if (not authorized) {
response.sendRedirect(some location);
return; // don't bother doing anything else
}
If you opened any jdbc connections be sure to close them before returning.
Sean
Web Solutions That Work Developing custom web solutions designed
specifically to accomplish the unique objectives of our clients. Phone
503-639-2727 Fax 503-639-0807
- Original Message -
From: Guy Rouillier [mailto:[EMAIL PROTECTED]
Sent: Monday, January 19, 2004 5:36 PM
To: Tomcat Users List
Subject: Mozilla showing JSP source code
[snip]
(4) The most reliable way to see this fail is via a redirect. This
happens most frequently on the secure half of our website (https). On
those pages, we have an authentication header at the top of each page:
%@ include file=/includes/authenheader.jspf %
Inside this file, we check some session variables, and if they don't
have the right set of values (or those values don't exist) we
response.sendRedirect() to a login page. During this redirect, I
*always* see the source for the login page - the login page has not come
up cleanly one time. This page is very small, and neither the buffer or
timeout changes help.
If anyone has any ideas on how to address this problem, I'm willing to
try anything. I really am out of ideas and don't know where to go next.
Thanks for any help.
--
Guy Rouillier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Convert Text to Image [OT]
Use JMagick in a servlet, or use php with freetype and libgd. Make a template button, then add text on the fly. Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Andoni [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 5:13 AM Subject: Convert Text to Image [OT] Hello, Does anyone know of a tool for Converting Text to images so that I can still have image buttons on my site while having it localised? Thanks, Andoni. PS: I have taken a look at AcmeGif I am looking to see if there is something better though. Or tutorial help on AcmeGif. Acme GIF is at: http://www.acme.com/java/software/Acme.JPM.Encoders.GifEncoder.html Ta. A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lock on database file not being released...
Hi, Is your jsp/servlet forwarding or redirecting to another jsp/servlet/html page before close() is called on the connection? Dreamweaver will automagically create jsp pages that fall prey to this gotcha. If you have access to the log files, log the opening and closing of the connection, and see if what you think is happening is in fact happening. Sean - Original Message - From: George Sexton [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Sunday, December 07, 2003 1:15 PM Subject: RE: Lock on database file not being released... One other question. What is the setting of AutoCommit? Are you setting it to TRUE? -Original Message- From: Chaikin, Yaakov Y (US SSA) [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 2:13 PM To: Tomcat Users List Subject: RE: Lock on database file not being released... However, I have used this driver before in a standalone app and when you close a connection, it certainly does release the lock on the database file. This makes me think, you didn't use pooling in this standalone app. Therefor check weather you close all your ResultSets and Statements. In standalone apps where no pooling is involved, they are caught by the garbage collector, but not in connection pooling. Trapped into this myself. Steffen, I tried what you said and closed the ResultSet and Statement before I close the Connection. Still same affect. Any other ideas anyone? I highly doubt it's the driver. I would bet that I am doing something wrong. I just can't figure out what it is. Thanks, Yaakov. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTP instead of FTP downloads with Tomcat
How about:
create an jsp that requires a login using a private password file or
database table, have it read the names of the files (using java.io) in the
folder you want them to be able to retrieve, and create links to another jsp
(using a session to maintain your login, and probably the directory to get
the files from as well) that does something like:
java.io.File f = new java.io.File (retrievalpath + fileName);
response.setContentType(application/octet-stream); // or the appropriate
mime type if you want to work that out
response.setHeader(Content-Disposition, inline;filename= + fileName +
); // can also change inline to attachment
response.setContentLength((int)f.length());
response.flushBuffer();
ServletOutputStream thisOut = response.getOutputStream();
byte[] buf = new byte[1024];
int numRead = 0;
while ((numRead = reader.read(buf)) = 0) {
thisOut.write(buf, 0, numRead);
}
reader.close();
thisOut.flush();
when you link to the retriever jsp, make sure you have the
fileName=(someFileName) last, and then IE will not try to open a .doc in
explorer instead of the word plugin when you set the disposition to inline.
something like:
getfile.jsp?fileName=some.doc
This allows you greater control over what the user gets to see, and how it
is presented.
Hope this helps.
Sean
Web Solutions That Work Developing custom web solutions designed
specifically to accomplish the unique objectives of our clients. Phone
503-639-2727 Fax 503-639-0807
- Original Message -
From: Tom Bednarz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2003 9:45 PM
Subject: HTTP instead of FTP downloads with Tomcat
Hi,
Could anybody please give me some hints how to solve the following problem:
Some of my customers cannot use FTP from their offices due to security
restrictions. I have to offer them the possibility to download files using
the HTTP protocol.
I use TOMCAT but have the listings tag set to false in the default servlet
tag of web.xml to deny directory listings.
The idea is, that I have a virtual directory that points to the customers
directory on the FTP Server and shows its contents in the browser. I think
it should work with a customer specific login. Could anybody please give me
some additional pointers what I exactly have to configure to make this one
working?
Many thanks
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: double slash before context reveals source in latest tomcat3? (apache 1.3.27)
Thanks again, compiled a new mod_jk, and all is good now! Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807 - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 8:01 PM Subject: Re: double slash before context reveals source in latest tomcat3? (apache 1.3.27) There was a bug like this in mod_jk prior to 1.2.5. If that's the case, then Tomcat4 won't help you since it is Apache that is serving the source (which is the usual case with this type of bug :). Try upgrading to mod_jk 1.2.5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
double slash before context reveals source in latest tomcat3? (apache 1.3.27)
Hello all, I looked around on the web to see if this was a known problem, but didn't find any reference to double slash problems since 3.2. I am hoping to avoid going to tomcat4 right now because there were alot of configuration changes that I don't want to deal with, and other than this rather ugly problem, everything else is working great. I am using: servletapi3-3.3.1a-1jpp.noarch.rpmxerces-j2-2.2.1-2jpp.noarch.rpmtomcat3-3.3.1a-2jpp.noarch.rpmxml-commons-1.0-0.b2.3jpp.noarch.rpmxml-commons-apis-1.0-0.b2.3jpp.noarch.rpm and tomcat-mod-3.3.1-1 apache-1.3.27-2 What I am seeing is that a url like http://dom.ain/context/some.jsp returns the compiled page but http://dom.ain//context/some.jsp returns the source to the page where http://dom.ain/context//some.jsp does not. I would love to hear that this is a simple config problem, and to be directed a place in TFM where I might R about how to fix it. :-) Thanks! Sean Web Solutions That Work Developing custom web solutions designed specifically to accomplish the unique objectives of our clients. Phone 503-639-2727 Fax 503-639-0807
Re: double slash before context reveals source in latest tomcat3? (apache 1.3.27)
Thanks, That was my suspicion! Sean - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 8:01 PM Subject: Re: double slash before context reveals source in latest tomcat3? (apache 1.3.27) There was a bug like this in mod_jk prior to 1.2.5. If that's the case, then Tomcat4 won't help you since it is Apache that is serving the source (which is the usual case with this type of bug :). Try upgrading to mod_jk 1.2.5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
