You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Kevin Sonney <ke...@webslingerz.com> on 2000/05/03 17:23:44 UTC
LDAP Processor Modification
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. Whic 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. I'm sure I could add a
couple of other special cases, but don't have a need for them. yet. *grin*
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*).
Here's the diff :
------------ Begin Diff - Cut Here ------------
--- LdapQueryCreator.java Wed May 3 11:12:26 2000
+++ LdapQueryCreator.java.kes Wed May 3 11:12:07 2000
@@ -82,7 +82,14 @@
int rindex = query.indexOf(rdelim,offset+llength);
if (rindex < 0 || rindex < lindex) break;
String name = query.substring(lindex+llength,rindex);
- String value = req.getParameter(name);
+ String value = req.getParameter(name);
+ if (value == null) {
+ if (name.equalsIgnoreCase("remote_user")) {
+ value = req.getRemoteUser();
+ } else {
+ value = req.getHeader(name);
+ }
+ }
if (value == null) break;
query = query.substring(0,lindex)+value+query.substring(rindex+rlength);
offset = lindex+value.length();
------------- End Diff - Cut Here -------------
--
- Kevin Sonney
kevin@webslingerZ.com
Re: LDAP Processor Modification
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Sat, 6 May 2000, Ricardo Rocha wrote:
> Kevin's proposed patch/hack is to explicitly check for the request's
> remote user or named header:
Correct. It's a quick & dirty, to get the functionality I need *RIGHT
NOW*. However, upon reviewing the proposed query string parameter stuff
you sugested, I'm now inclided to make those modifications. Well, ok,
sometime this week, since, like donald, I've got some client work ythat
needs done beforehand. *grin*
> It occurs to me that, instead of "wiring" these cases, we might
> extend the LDAP query string parameter syntax to support:
*trim*
> all in the name of simplicity and backwards compatibility...
Which is always nice, I'll admit *grin*
> Hmmm... this smells of FS...
FS? I'm guessing "full support", but this is an acronym I'm not used to
*grin*.
> Yes!!!
I guess I just volunteered, withuot meaning to? Uh-oh....
> If we had an LDAP logicsheet, the above 3 cases could be
> easily rewritten as:
*trim*
> with no additional coding or special case handling...
Exactly. That was the functionality I really wanted. However, the time
it'll take me to write the logic sheet versus the time it takes me to add
the patch was why I wrote the patch first.
However, now that I have something that works for my client(s), I can
begin writing something a little more useful to the rest of the
world. *grin*
--
- Kevin Sonney
kevin@webslingerZ.com
Re: LDAP Processor Modification
Posted by Ricardo Rocha <ri...@apache.org>.
> 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();
}
:-)
Re: LDAP Processor Modification
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Thu, 4 May 2000, Stefano Mazzocchi wrote:
> I know Ricardo and James were talking about this and had something
> working.... guys, still awake?
I'd love to have it, if they ever finish. Or do some playing/testing when
it's almost ready...
--
- Kevin Sonney
kevin@webslingerZ.com
Re: LDAP Processor Modification
Posted by Stefano Mazzocchi <st...@apache.org>.
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. Whic 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. I'm sure I could add a
> couple of other special cases, but don't have a need for them. yet. *grin*
>
> 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*).
I know Ricardo and James were talking about this and had something
working.... guys, still awake?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------