cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricardo Rocha <rica...@apache.org>
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"?>
  <page>
   <ldap-defs>
    <ldap-server name="searchlight">
     <initializer>com.sun.jndi.ldap.LdapCtxFactory</initializer>
     <ldap-serverurl>ldap://ldap.weber.edu</ldap-serverurl>
    </ldap-server>
   </ldap-defs>
   <ldap-query server="searchlight" ldap-searchbase="">
	sn=*Green*
   </ldap-query>
  </page>
  
An LDAP request string may contain one or more LDAP parameters
enclosed by "{@" and "}":

   <ldap-query server="searchlight" ldap-searchbase="">
	sn=*{@color}*
   </ldap-query>

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

  http://localhost/ldap.xml?color=Green

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: 
    {@color}
    {@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:

    {@color}

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*).

Yes!!!

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"/>*
     </ldap-query>

2) Remote user:
     <ldap-query server="searchlight" ldap-searchbase="">
         un=<request:get-remote-user/>
     </ldap-query>

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

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()) {
    ricardo.zzz();
  }
:-)

Mime
View raw message