cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <>
Subject Re: LDAP Processor Modification
Date Sun, 07 May 2000 03:59:42 GMT
> Kevin Sonney wrote:
> So I'm hacking happily away at a site that needs LDAP, XSP and SQL - in
> that order. The problem is, I need some HTTP Request info to process the
> LDAP query.
> No problem, right? Just use XSP. Can't - I need XSP *AFTER* LDAP in order
> to complete the SQL Query. Which sets the stage for this hack :
> What this patch does is it *FIRST* tries to get the requested string out
> of the Request Parameters. If the name isn't found there, we then check to
> see if it's an request for the REMOTE_USER, and send that. Finally, we
> check the rest of the Header for the variable.

Let's provide some context for those not familiar with the code:

LDAP query strings are passed to the LDAP processor inside the
<ldap-query>  element:

  <?cocoon-process type="ldap"?>
    <ldap-server name="searchlight">
   <ldap-query server="searchlight" ldap-searchbase="">
An LDAP request string may contain one or more LDAP parameters
enclosed by "{@" and "}":

   <ldap-query server="searchlight" ldap-searchbase="">

In this case, the servlet request is expected to contain a "color"
parameter to be substituted in the LDAP query string:


Kevin's application needs to extend this functionality so that an
LDAP query parameter can be substituted from:

1) a servlet request parameter (the above case)
2) the servlet request remote user (request.getRemoteUser())
3) a servlet request header (request.getHeader(name))  

In addition to these cases, there could be some others:

> I'm sure I could add a couple of other special cases, but don't have a need
> for them. yet. *grin*

Kevin's proposed patch/hack is to explicitly check for the request's
remote user or named header:

> + String value = req.getParameter(name); 
> + if (value == null) { 
> + if (name.equalsIgnoreCase("remote_user")) { 
> + value = req.getRemoteUser(); 
> + } else { 
> + value = req.getHeader(name); 
> + } 
> + } 

It occurs to me that, instead of "wiring" these cases, we might
extend the LDAP query string parameter syntax to support:

1) Request parameters: 
    {@parameter(color)} // Mapped to request.getParameter()

2) Request headers:
    {@header(my_header)} // Mapped to request.getHeader()

3) Request CGI variables:
    {@variable(REMOTE_USER)} // Mapped to the appropriate request.getXXX() method

Case #1 (request parameter) may be shortened to:


all in the name of simplicity and backwards compatibility...

Hmmm... this smells of FS...

> This should also be considered a work-around until someone can hack out
> an LDAP TagLib (hey, that someone could be me, but I'm not that motivated
> yet *grin*).


If we had an LDAP logicsheet, the above 3 cases could be
easily rewritten as:

1) Request parameter:
     <ldap-query server="searchlight" ldap-searchbase="">
         sn=*<request:get-parameter name="color"/>*

2) Remote user:
     <ldap-query server="searchlight" ldap-searchbase="">

3) Request header:
     <ldap-query server="searchlight" ldap-searchbase="">
         mh=<request:get-header name="my_header"/>

with no additional coding or special case handling...

> Stefano Mazzocchi wrote: 
> I know Ricardo and James were talking about this and had something
> working.... guys, still awake?

  // Just kiddin'...
  while (!ldap.isLogicsheet()) {

View raw message