You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Anil Vijendran <ak...@pipedream.org> on 2000/04/08 07:28:43 UTC
[Fwd: LDAP and SecurityContext]
Mark,
You might have accidentally sent this message to
jakarta-tomcat-cvs@apache.org. The right list is
tomcat-dev@jakarta.apache.org.
mark@mjwilcox.com wrote:
> Hi,
> I'm working on a chapter for an upcoming book on JSPs by Wrox
> Press. My chapter is on JSP and Security. One of the topics I'm
> going to cover is how to add an LDAP based interceptor. I know
> that I can use SecurityCheck.java as a model, but should I just add
> my LDAP code to that class or create a new class (e.g.
> LDAPSecurityCheck.java) and if so where do I tell Tomcat where to
> locate it?
>
> Also is it possible to put any configuation information in the
> web.xml file for the Security Interceptor to use (e.g. things like
> LDAP hostname, search base, etc)? Or must I hardcode this or put
> into a seperate properties file?
>
> If someone can point me in the right direction, I'll be happy to pass
> back whatever code I write. I might be able to give even something
> more valueable, documentation! ;)
>
> thanks,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Peace, Anil +<:-)
oops JAAS does require JDK 1.3
Posted by ma...@mjwilcox.com.
Well I just started poking through the documentation for JAAS
again and yup it states there at the top "Note that JAAS 1.0
requires that you have JavaTM 2 SDK, v 1.3 or the JavaTM 2
Runtime Environment, v 1.3 already installed."
I'd think that rules it out for now since 1.3 isn't even out yet. (Now
for the book, I'm caught in a catch 22. I should probably cover 1.3
since it likely will be out by the time the book hits the shelves in
early summer, but do I risk blowing up my Java stuff with a beta
JVM?)
aarrrgh.
Mark
Re: RequestUtil sources
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Costin Manolache wrote:
> We are now in open development season for 3.2, any patch is wellcome !
ok
> And please keep reading the code !
Then let me tell what we want.
Response interface have get/setCharacterEncoding() methods. But
Request don't have it. I not quite understand why. Actually if we will
have this for Request then we can detect CharacterEncoding of user
request or just set default encoding in web application or from system
property file.encoding. I know it's out from JSDK specification but it's
really necessary for national languages and local character encodings.
CharacrerEncoding from request nust be used in parser of request
parameters for correct CharacrerEncoding conversion. For example:
public static String unUrlDecode(String data)
This method get string with %xx encoded characters. But if Servlet
engine and Web browser works with different caracter encoding you will
get wrong String after decode %xx data. For example in russian koi8-r
(ibm-878) and russian Cp1251 (windows-1251) caodepages code %c0 is two
different cahracters.
The same problem with POST method. There used this code:
ServletInputStream is=request.getInputStream();
Hashtable postParameters = HttpUtils.parsePostData(contentLength,
is);
Then lets look ar parsePostData
----------
static public Hashtable parsePostData(int len,
ServletInputStream in)
{
// XXX
// should a length of 0 be an IllegalArgumentException
if (len <=0)
return new Hashtable(); // cheap hack to return an empty hash
if (in == null) {
throw new IllegalArgumentException();
}
//
// Make sure we read the entire POSTed body.
//
byte[] postedBytes = new byte [len];
try {
int offset = 0;
do {
int inputLen = in.read (postedBytes, offset, len - offset);
if (inputLen <= 0) {
String msg = lStrings.getString("err.io.short_read");
throw new IllegalArgumentException (msg);
}
offset += inputLen;
} while ((len - offset) > 0);
} catch (IOException e) {
throw new IllegalArgumentException(e.getMessage());
}
// XXX we shouldn't assume that the only kind of POST body
// is FORM data encoded using ASCII or ISO Latin/1 ... or
// that the body should always be treated as FORM data.
//
try {
String postedBody = new String(postedBytes, 0, len,
"8859_1");
return parseQueryString(postedBody);
} catch (java.io.UnsupportedEncodingException e) {
// XXX function should accept an encoding parameter & throw
this
// exception. Otherwise throw something expected.
throw new IllegalArgumentException(e.getMessage());
}
}
----------
So. Why there always used 8859_1 ? In real world exist not only this
encoding.
I think (and still hope) that this situation must be changed before
Tomcat release.
I would like to see in Tomcat's (and in JSDK specification) Request
additional methods for setting and getting CharacterEncoding of request
and this information must used in request parameter parser.
Thank you.
Eugen Kuleshov.
Re: RequestUtil sources
Posted by Costin Manolache <co...@eng.sun.com>.
We are now in open development season for 3.2, any patch is wellcome !
And please keep reading the code !
Costin
Eugen Kuleshov wrote:
> Costin Manolache wrote:
>
> > > Could someone tell me for what need to cut contentType if it not used
> > > below?
> > Would you prefer a for(i=1; i<500; i++ ) {} :-)???
>
> sometime ago I heard that Tomkat will have good performance.
> It's good idea to add some code like this for performance increasing
> after removing this. :)
>
> > That's why open source is good - people can find this kind of code...
> > I'll try to remove this ( and many other examples ). I'm more concerned with
> > the
> > atrocities in SimpleMapper and the header parsing and the date parsing.
>
> It's ok. But long time I've tryed to fix some charset related things
> in parameter parser but still without success. Would you like if I'll
> offer some fix (or another implementation) of this parser for GET, POST
> and multipart requests?
>
> > I guess the original idea was to extract the encoding ( what's after ";" )
> > and use it when reading the form data.
>
> good idea, but unfortunately still not implemented. :(
>
> Eugen Kuleshov.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: RequestUtil sources
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Costin Manolache wrote:
> > Could someone tell me for what need to cut contentType if it not used
> > below?
> Would you prefer a for(i=1; i<500; i++ ) {} :-)???
sometime ago I heard that Tomkat will have good performance.
It's good idea to add some code like this for performance increasing
after removing this. :)
> That's why open source is good - people can find this kind of code...
> I'll try to remove this ( and many other examples ). I'm more concerned with
> the
> atrocities in SimpleMapper and the header parsing and the date parsing.
It's ok. But long time I've tryed to fix some charset related things
in parameter parser but still without success. Would you like if I'll
offer some fix (or another implementation) of this parser for GET, POST
and multipart requests?
> I guess the original idea was to extract the encoding ( what's after ";" )
> and use it when reading the form data.
good idea, but unfortunately still not implemented. :(
Eugen Kuleshov.
Re: RequestUtil sources
Posted by Costin Manolache <co...@eng.sun.com>.
> Could someone tell me for what need to cut contentType if it not used
> below?
Would you prefer a for(i=1; i<500; i++ ) {} :-)???
That's why open source is good - people can find this kind of code...
I'll try to remove this ( and many other examples ). I'm more concerned with
the
atrocities in SimpleMapper and the header parsing and the date parsing.
I guess the original idea was to extract the encoding ( what's after ";" )
and use it when reading the form data.
Costin
RequestUtil sources
Posted by Eugen Kuleshov <an...@hco.kollegienet.dk>.
Hello!
I just look at some sources related to request parameters parsing.
Lets look at
jakarta-tomcat\src\share\org\apache\tomcat\util\RequestUtil.java
----------------
[skipped]
/**
* Usefull methods for request processing. Used to be in ServerRequest
or Request,
* but most are usefull in other adapters.
*
* @author James Duncan Davidson [duncan@eng.sun.com]
* @author James Todd [gonzo@eng.sun.com]
* @author Jason Hunter [jch@eng.sun.com]
* @author Harish Prabandham
* @author costin@eng.sun.com
*/
public class RequestUtil {
public static Hashtable readFormData( Request request ) {
String contentType=request.getContentType();
if (contentType != null) {
if (contentType.indexOf(";")>0)
contentType=contentType.substring(0,contentType.indexOf(";")-1);
contentType = contentType.toLowerCase().trim();
}
int contentLength=request.getContentLength();
if (contentType != null &&
contentType.startsWith("application/x-www-form-urlencoded"))
{
try {
ServletInputStream is=request.getInputStream();
Hashtable postParameters =
HttpUtils.parsePostData(contentLength, is);
return postParameters;
}
catch (IOException e) {
// nothing
// XXX at least warn ?
}
}
return null;
}
etc...........
----------
Could someone tell me for what need to cut contentType if it not used
below?
Eugen Kuleshov.
RE: building the jserv connector
Posted by Brill Pappin <br...@jmonkey.com>.
Thanks, that little script was all I needed... did the trick nicely.
Why isn't it in the source tree?
- Brill Pappin
> -----Original Message-----
> From: Jun Inamori [mailto:j-office@osa.att.ne.jp]
> Sent: April 8, 2000 1:25 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: building the jserv connector
>
>
> Hello,
>
> Assuming that Apach is complied as DSO support, you can compli the JServ
> module by 'apxs'.
> I uploaded the documentation for building the JServ module for
> Tomcat3.1Beta on my WWW site.
> So please read:
> http://www.oop-reserch.com/tomcat/
> The shell script for compiling the JServ module is also available there.
>
> I hope this will help you.
> Happy Java programming!
>
> Jun Inamori
> E-mail: j-office@osa.att.ne.jp
> URL: http://www.oop-reserch.com
>
>
> Brill Pappin wrote:
> >
> > I'm having trouble building the jserv connector for Solaris 7...
> > I think really the problem is that I'm not all that familiar
> with Make...
> >
> > Can someone outline the steps, or the command I'll have to run?
> >
> > - Brill Pappin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: building the jserv connector
Posted by Jun Inamori <j-...@osa.att.ne.jp>.
Hello,
Assuming that Apach is complied as DSO support, you can compli the JServ
module by 'apxs'.
I uploaded the documentation for building the JServ module for
Tomcat3.1Beta on my WWW site.
So please read:
http://www.oop-reserch.com/tomcat/
The shell script for compiling the JServ module is also available there.
I hope this will help you.
Happy Java programming!
Jun Inamori
E-mail: j-office@osa.att.ne.jp
URL: http://www.oop-reserch.com
Brill Pappin wrote:
>
> I'm having trouble building the jserv connector for Solaris 7...
> I think really the problem is that I'm not all that familiar with Make...
>
> Can someone outline the steps, or the command I'll have to run?
>
> - Brill Pappin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
building the jserv connector
Posted by Brill Pappin <br...@jmonkey.com>.
I'm having trouble building the jserv connector for Solaris 7...
I think really the problem is that I'm not all that familiar with Make...
Can someone outline the steps, or the command I'll have to run?
- Brill Pappin
Re: [Fwd: LDAP and SecurityContext]
Posted by Costin Manolache <co...@eng.sun.com>.
>
> >
> > The standard for authentication and authorization is JAAS - and probably
> > you should use an LDAP provider for JAAS ( most likely
> > there is no need - since JAAS can work with PAM, and PAM
> > can use LDAP or Radius and few other systems).
>
> From what I know JAAS requires JDK 1.3. So maybe it's not a suitable
> solution.
It can't be the "default" or "official" interceptor, but it can be provided
and
used. Yes, the majority voted for 1.1 support - but it's important to tolerate
the minority :-) That's the main idea of interceptors - to allow independent
code that is not designed by vote.
( it will be usefull to have a JDK1.1 LDAP authentication interceptor, or PAM
or NT bridges that JAAS provides )
Costin
Re: [Fwd: LDAP and SecurityContext]
Posted by Costin Manolache <co...@eng.sun.com>.
I would extend SecurityCheck and just override 2 methods that
check the password and the group ( role ). It's the simplest
method - and you'll have your own interceptor that you can
plug in ( without changing the original ).
Or you can start fresh and write a new security interceptor -
maybe reusing some code from SecurityCheck. You'll
probably end up with better code - SecurityCheck is still at
"experiment" stage.
Regarding configuration we just want a consistent method of
configuration. Every component ( including interceptors) have to
respect JavaBean conventions and expose all configurable
properties as normal setter methods. Tomcat can work
with programmatic configuration ( i.e. no config file at all,
just a java program that creates the objects and set them
up with arbitrary values ) or it can be plugged into any
program and use the native config system ( by using a
simple bridge).
server.xml is our "default" or standalone mechanism.
If a standard for server configuration will be developed and
agreed by major servers - we can provide it as an alternative. There are
plans to develop LDAP configuration - and we want to integrate
with any reasonable config system.
Please don't use a properties file and don't hardcode any
configuration code in your component - just provide setters.
( and if possible, check for property change events :-)
Costin
> However, JAAS requires JDK 1.2 or 1.3 (so still perhaps not the
> best solution if you want to still be able to use 1.1.x JVMs). For
> my chapter that's ok, but I don't know how the tomcat group feels
> about requiring JDK 1.2+.
>
> BTW There is a JAAS LDAP provider. I still may provide code for a
> LDAP JAAS provider because I don't know yet if Sun has provided
> the source for the LDAP provider.
>
> I guess perhaps I should rephrase the question. If I add JAAS
> capability to Tomcat, should it go directly into the SecurityCheck
> class? Or should I add a JAASSecurityCheck class?
>
> Even with JAAS you still need a way to tell Tomcat what JAAS
> providers to load and any configuration options to use for those
> providers. So does that information go into the server.xml file, or
> should I use a seperate properties file?
Re: [Fwd: LDAP and SecurityContext]
Posted by ma...@mjwilcox.com.
First I apologize for sending to the wrong list. In my head it was
tomcat-dev, but my fingers late at night had a mind of their own. ;)
Yes I know about JAAS and I am going to use JAAS in the
chapter.
However, JAAS requires JDK 1.2 or 1.3 (so still perhaps not the
best solution if you want to still be able to use 1.1.x JVMs). For
my chapter that's ok, but I don't know how the tomcat group feels
about requiring JDK 1.2+.
BTW There is a JAAS LDAP provider. I still may provide code for a
LDAP JAAS provider because I don't know yet if Sun has provided
the source for the LDAP provider.
I guess perhaps I should rephrase the question. If I add JAAS
capability to Tomcat, should it go directly into the SecurityCheck
class? Or should I add a JAASSecurityCheck class?
Even with JAAS you still need a way to tell Tomcat what JAAS
providers to load and any configuration options to use for those
providers. So does that information go into the server.xml file, or
should I use a seperate properties file?
thanks,
Mark
On 8 Apr 00, at 17:30, Wong Kok Wai wrote:
>
>
> Costin Manolache wrote:
>
> >
> > The standard for authentication and authorization is JAAS - and probably
> > you should use an LDAP provider for JAAS ( most likely
> > there is no need - since JAAS can work with PAM, and PAM
> > can use LDAP or Radius and few other systems).
>
> >From what I know JAAS requires JDK 1.3. So maybe it's not a suitable
> solution.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
Re: [Fwd: LDAP and SecurityContext]
Posted by Wong Kok Wai <wo...@pacific.net.sg>.
Costin Manolache wrote:
>
> The standard for authentication and authorization is JAAS - and probably
> you should use an LDAP provider for JAAS ( most likely
> there is no need - since JAAS can work with PAM, and PAM
> can use LDAP or Radius and few other systems).
Re: [Fwd: LDAP and SecurityContext]
Posted by Costin Manolache <co...@eng.sun.com>.
Implementing LDAP-based authentication is not that most
users will ever do. I don't know if it's a good idea to get
into a tomcat-specific implementation, you should recomend
only standard APIs, not product-specific.
The standard for authentication and authorization is JAAS - and probably
you should use an LDAP provider for JAAS ( most likely
there is no need - since JAAS can work with PAM, and PAM
can use LDAP or Radius and few other systems).
SecurityCheck is just a bridge between tomcat and the real API.
Of course - there are many other ways to implement security,
but the great advantage of interceptors is that it is possible to
implement multiple systems, and then compare and decide what's
better ( instead of guessing without code ).
Costin
>
> > Hi,
> > I'm working on a chapter for an upcoming book on JSPs by Wrox
> > Press. My chapter is on JSP and Security. One of the topics I'm
> > going to cover is how to add an LDAP based interceptor. I know
> > that I can use SecurityCheck.java as a model, but should I just add
> > my LDAP code to that class or create a new class (e.g.
> > LDAPSecurityCheck.java) and if so where do I tell Tomcat where to
> > locate it?
> >
> > Also is it possible to put any configuation information in the
> > web.xml file for the Security Interceptor to use (e.g. things like
> > LDAP hostname, search base, etc)? Or must I hardcode this or put
> > into a seperate properties file?
> >
> > If someone can point me in the right direction, I'll be happy to pass
> > back whatever code I write. I might be able to give even something
> > more valueable, documentation! ;)
> >
> > thanks,
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> --
> Peace, Anil +<:-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Strange Ant error...
Posted by Brill Pappin <br...@jmonkey.com>.
I keep getting a strange error from Ant on Solaris...
Error chmodjava.io.IOException: Not enough space
Now I know there is enough space... I guess something is wrong with the
chmod taskdef?
- Brill Pappin
*.jsp mapping to tomcat. Where is the decision?
Posted by "Alexey V. Meledin" <av...@webclub.ru>.
Hi,
tomcat-developers!
Sorry for writing to this list, but problem is special, I thing that
tomcat-users can't answer.
I have FreeBSD 3.3., Apache 1.3.12, DSO=max, mod_charset.so,
mod_php3.so + many standart modules loaded in. Tomcat 3.1. beta1
Additionaly I have mod_jserv.so v1.1.BETA 3, compiled from FreeBSD
ports collection. I need that, because tomcat 2 weeks ago was not
compatible with ApJ1.2. protocol from lastest mod_jserv 1.1. final
release.
1. Does situation changed?
2. How many differences are in mod_jserv binary provided from
jakarta.apache.org and mod_jserv beta 3, provided from
java.apache.org?
I ask this question because:
2.1. I can't mount context "context_name", like:
2.1.1. ApjServMount /any_name /context_name
(Minimalistic Users Guide allows such mappings)
I can only mount like this:
2.1.2. ApjServMount /context_name/(uri_map || valid_path || NONE) /context_name
(servlet specification allows only this way. But does mod_jserv binary
from jakarta.apache.org rewrites in chapter 2.1.1(see above)
"any_name" URI to /context_name via Apj1.2. protocol?)
3. Minimalistic Users Guide said to me, that I can use the following
sheme:
====================================================================
Alias /examples /usr/local/jakarta3.1s/build/tomcat/webapps/examples
<Directory "/usr/local/jakarta3.1s/build/tomcat/webapps/examples" >
Options Indexes FollowSymLinks
AddType test/jsp .jsp
AddHandler jserv-servlet .jsp
</Directory>
<Location /examples/WEB-INF/>
AllowOverride None
deny from all
</Location>
<LocationMatch /examples/*.jsp>
SetHandler jserv-servlet
</LocationMatch>
ApJServMount /examples/servlet /examples #(6)
====================================================================
#(6) only works, when I requesing servlets via /examples/servlet
uri-mappings.
jserv-servlet handler doesn't work at all! :(
1. I've got "Segmentation Fault" in error_log requesting
http://host/examples/jsp
JSP examples works only when I pass all requests to
http://host/examples/jsp, making additional
ApjServMount /examples/jsp /examples
I've tried to analize mod_jserv.c, but it hard to make it quickly.
4. Can anyone give me the source of mod_jserv.so module situated at
jakarta.apache.org?
If I'm a stupid, then help me, please :(
Alexey V. Meledin <av...@webclub.ru>
> InterForge Developers Group, St-Petersburg, Russia
New: http://www.crossroad.ru; http://www.garoway.com
> > > > > > "InterForge to Forge Ahead" > > > > > > >