Re: Cache problem with IE
You could try having the JSP set its modified time to 'now', using a
java.util.Calendar object. That should cause the cache on the browser to
retrieve an updated copy of the page. I don't recall how to do this in
JSP land, but servlets do it by implementing getLastModified(), derived
from HttpServlet. The idea is to set a header in the response object to
indicate the modification time as being a few milliseconds ago, but
I don't recall the exact name of the header that needs to be set.
Sorry I couldn't be more helpful.
- Roby
Zsolt Koppany wrote:
Hi,
with the code below I can get netscape not to cache a jsp page but it
does not work with Internet-Explorer.
Does anybody know why?
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");\
Zsolt
--
Zsolt Koppany
Intland GmbH www.intland.com
Schulze-Delitzsch-Strasse 16
D-70565 Stuttgart
Tel: +49-711-7871080 Fax: +49-711-7871017
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Off topic: Single login for separate web applications?
I'm using JAAS to handle authentication. One of the things that you're able to do is use pluggable authentication under Windows and Solaris (using the Sun implementations) and Linux (with the IBM implementation), or authenticate against a database (which is what I'm doing). The end result of the authentication process is a Subject having one or more Principals and public or private credentials (which can be any Java object). You can add either the Subject itself (with all of its attached state, in a secure environment), or just its public credentials (as a token or key in a non-secure environment) to the session object in JSPs and servlets to indicate an authenticated user. You might want to check this out: http://java.sun.com/products/jaas. Hope this helps. - Roby [EMAIL PROTECTED] wrote: Yes, but than then client would have to identify itself at the second webapp without being challenged for another login. The only way to accomplish this would be a session based cookie I guess, in addition to this centrally stored information. I was hoping for some standard approach/protocol that I was not aware of. But maybe it just isn't there (yet). Thanks, Wilko "Sam Newman" [EMAIL PROTECTED] on 13-03-2001 15:15:44 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Wilko Hische/HADV/NL) Subject: Re: Off topic: Single login for separate web applications? Having a central repository of logins/passwords would work from one end = e.g. when connecting to one of your servers, that server communicates with the central repository to veriy the login/password. However, when going to another webapp that webapp needs to know you've been authorised. perhaps once authorised, you could store information about the client at the central respository. When a webapp gets a connection from that client, it looks ion the central repository to see if that client has been authorised. Not sure on what info would work though sam - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 12:38 PM Subject: Off topic: Single login for separate web applications? Hi, Sorry for posting this off topic question. I would really appreciate any pointers into the right direction. What I would like to know is what you would need in general to create a single login to different web applications on different web servers (and possibly platforms)? I gues the servers would need some shared repository for login/passwords, but how would it be possible after logging in to one server to pass on this fact to the other servers? I hope the answer is as simple as the question, Wilko Hische - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Encrypting password
If you just need a test certificate for experimentation, check with Thawte: theirs are free for application testing, and they don't trigger the client-side 'Add a Certificate' dialog. Once you work out the bugs, try Verisign or RSA for a production certificate. - Roby Sam Newman wrote: Tim Wrote: If you are using passwords as the key, then it is unlikely that using 1024 vs. 128 bit means a bit of difference. Unless you are requiring that users use a 250 character password. The entropy of 6-10 digit passwords is such that they are the weak point no matter how many bits you use 64, even if they are "good" passwords. If you worried, you're worried about the wrong thing. Throwing more bits at it ain't going to help. I really should read up on cryptography :-) ta for the info. Looking at verisign now for pircing - but thier certificates seem to cost anywhere from $200 to $2000. Just got to work out which ones we need sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: select query
What kind of Date object are you using? There's the standard java.util.Date, and then there's java.sql.Date passed into and returned by SQL queries. You may need to convert from one to the other. The best way to do that is by using a java.util.Calendar object. Hope this helps. - Roby "Heijns, P.J.B." wrote: Hi I use interbase and tomcat. I have made a jsp page, where I do a select query on the database. When I query a table with a date object in it, the jsp page generates the following error: "javax.servlet.servletexecption: [interclient] [interbase] Dynamic sql error sql error code = -804 data type unknown Client sql dialect 1 does not support reference to DATE datatype" If I do a select query on a table without a date object, everyting goes fine. What do I wrong? Thanks Pieter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Cache problem with IE
In looking over the HTTP/1.1 spec, the header to set is 'Last-Modified'. In
the spec documentation, though, they state that there's 60 seconds of slop
allowed, in the event that the browser and server clocks are out of sync.
Still, they say that if the cached copy differs from the server copy by that
amount, the client must treat the cached copy as stale and reload it. Now,
as to whether IE abides by these rules or not...
Setting it in the JSP may be as simple as
'response.setHeader("Last-Modified",
java.util.Calendar.getInstance().getTime())', although you may need to
represent the time in ISO-9601 notation ('Wed, 15 Nov 1995 04:58:08 GMT').
Hope this helps.
- Roby
Joe Laffey wrote:
On Tue, 13 Mar 2001, Zsolt Koppany wrote:
No, there is no proxy, everything runs in a simple LAN.
You can also try adding the following at the top of your HTML document:
(in the HEAD)
META HTTP-EQUIV="Pragma" CONTENT="no-cache"
Though I don't know why it wouldn't work from the servlet. Have you tried
telnetting to your box and issuing an HTTP request manually? Perhaps the
headers are not actually getting set. This can happen if you send any
output to the output stream before setting the headers.
Joe Laffey
LAFFEY Computer Imaging
St. Louis, MO
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
JAAS/ClassLoader questions
Hi, folks: I'm trying to work out a variation of what appears to be a problem previously encountered via JNDI/JMS and Tomcat. My specific configuration has a little bit of a different slant, though. I'm attempting to follow this route: JSP-JAAS-EJB-database Previously, I was able to use a JSP to retrieve data through an entity EJB and it worked fine. When I started working with authentication via JAAS, I bundled a .jar file with my security classes, including the LoginModule-derived class that would be used to authenticate a user, and included it in my webapp/WEB-INF/lib directory. When I attempt to authenticate via the JSP, however, I get the following exception: Error: 500 Location: /scheduler/Login.jsp Internal Servlet Error: javax.servlet.ServletException: unable to find LoginModule class: org.sofbex.security.login.SchedulerModule at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:457) at Login_1._jspService(Login_1.java:110) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:500) at org.apache.tomcat.core.Handler.service(Handler.java:226) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:448) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:777) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:699) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:142) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:497) at java.lang.Thread.run(Thread.java:484) Root cause: javax.security.auth.login.LoginException: unable to find LoginModule class: org.sofbex.security.login.SchedulerModule at javax.security.auth.login.LoginContext.invoke(LoginContext.java:649) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:124) at javax.security.auth.login.LoginContext$3.run(LoginContext.java:530) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:527) at javax.security.auth.login.LoginContext.login(LoginContext.java:448) at Login_1._jspService(Login_1.java:81) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:500) at org.apache.tomcat.core.Handler.service(Handler.java:226) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:448) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:777) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:699) at org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:142) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:426) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:497) at java.lang.Thread.run(Thread.java:484) As I said, the org.sofbex.security.login.SchedulerModule class is included in security.jar, which is in the webapp/WEB-INF/lib directory. The jaas.jar and jaas_lm.jar files (supplied by the IBM JAAS for Linux implementation) are also included in the lib directory. I had written a main() method into the SchedulerModule class to test its operation, and it worked fine, so I don't think it's a security issue. I checked the supplied tomcat.policy file and added full security permissions for the webapp directory and below, to no avail. Was there a resolution found for this problem? Thanks for your help. Roby Gamboa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JAAS/ClassLoader questions
It doesn't look like this approach will work. JAAS=Java Authentication and
Authorization Service, a Sun Java extension
(http://java.sun.com/products/jaas).
For authentication, you construct a module for handling authentication services
for your application, and it has to implement
javax.security.auth.spi.LoginModule from jaas.jar. In my case, this was the
class that wasn't found in the original exception trace that I posted.
In addition, you have to add entries for 'providers' to the java.security file,
like so:
login.configuration.provider=com.ibm.security.auth.login.ConfigFile
login.config.url.1=file:/opt/Projects/Scheduler/webapp/WEB-INF/lib/scheduler.conf
auth.policy.provider=com.ibm.security.auth.PolicyFile
auth.policy.url.1=file:/opt/Projects/Scheduler/webapp/WEB-INF/lib/scheduler.policy
In this case, IBM has supplied the JAAS implementation for Linux (Sun only has
Windows and Solaris implementations available). The problem is that neither of
the classes mentioned implement java.security.Provider, so they can't be added
via Security.addProvider().
You then construct the configuration and policy files referenced. In the
configuration file indicated above, I've got the following entry:
Scheduler {
org.sofbex.security.login.SchedulerModule Required repository=schedule;
};
The format is:
[Application] {
[Login Module] [Constraint] [Options];
...
};
In my case, I'm only using one type of login module for authentication
purposes, SchedulerModule.
Although these classes provide the mechanism for getting at the security
configuration and policy, the class that manages access to the JAAS portion of
the security framework is javax.security.auth.login.LoginContext. You create a
new instance of this class, using your application's name as entered in the
.conf file indicated above ('Scheduler', in my case). When I attempt to
instantiate the LoginContext object, I get the exception that I referenced in
my original message.
Are there alternate mechanisms for loading providers?
- Roby
David Wall wrote:
I'm trying to work out a variation of what appears to be a problem
previously encountered via JNDI/JMS and Tomcat. My specific
configuration has a little bit of a different slant, though. I'm
attempting to follow this route:
JSP-JAAS-EJB-database
I figured out a work-around for JNDI/JMS. Actually, in my case it was just
for JNDI, though I was only using JNDI to use JMS! I have not used JAAS
before. Is it an extension? How is the extension loaded? You'll want to
make sure that the extension is loaded your code, and not by anything that
would be found in the standard CLASSPATH (as used by Tomcat), and it cannot
be done by including configuration information in a properties file or the
like.
For example, to use JCE, I had used the method of installing the provider by
putting an entry in the jre/lib/security/java.security file, and this had
the unfortunate side effect of causing those classes to be loaded by the
system class loaders rather than the JSP classloader that's going to look in
WEB-INF/lib for you. By loading the provider in my code instead
(Security.addProvider()) I was able to solve it. Hope this helps...
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
