You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Jesse Reynolds <li...@va.com.au> on 2001/01/30 08:37:11 UTC

Re: util:include-uri authentication (+cookies & form data)

At 7:44 PM +0000 20/12/00, Robin Green wrote:
>mika.borner@telia.fi wrote:
>>How do I use util:include-uri to include an external xml file if the file is
>>protected with basic authentication?.
>
>You'll have to edit the source code.
>
>src/org/apache/cocoon/processor/xsp/libary/java/util.xsl
>
>Please submit it as a patch if you get it working - thanks!


Mika (or anyone else) Did you get this working?

As well as basic authentication, I also need util:include-uri (or 
something else) to send cookies and form data...

Should I be looking at editing the util.xsl source code to do all 
this, with calls to the Servlet API? Or should I be looking at 
writing my own library tag?

Thanks

-jesse

-- 

       Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
                                                  jesse (at) va.com.au

Re: util:include-uri authentication (+cookies & form data)

Posted by Ulrich Mayring <ul...@denic.de>.
> On Tue, 30 Jan 2001, Jesse Reynolds wrote:
> 
> > Mika (or anyone else) Did you get this working?
> >
> > As well as basic authentication, I also need util:include-uri (or
> > something else) to send cookies and form data...

Perhaps you could use the auth taglib, then you can protect specific
pages and execute auth first and the other taglibs later.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: auth:taglib and Turbine Connection Pool

Posted by Ulrich Mayring <ul...@denic.de>.
Andreas Neuenschwander wrote:
> 
> Hi,
> 
> I have a question about the auth:taglib.
> 
> Everything works well, but there is one thing I don't understand.
> 
> Why isn't it possible to use the Connection Pool from Turbine?
> 
> At the moment I must setup in the login.xml file the
> 
> <connection>
>     <driver>...<driver>
>     <username>...<username>
>     <password>...<password>
>     <dburl>...<dburl>
> </connection>
> 
> all these parameters.
> 
> Is it possible to use the Turbine Connection Pool for the auth:taglib too?

First of all you should get the newest version, I just uploaded it, it
fixes some bugs. Also, the auth:fragment is not there anymore, look at
the samples how to achieve the same thing much easier now without
auth:fragment.

Then: why do you want to use the connection pool for authentication?
This is IMHO way too much overhead - it's ok to use it for regular
database database access, but auth just accesses the database once for
initial authentication (if you use authentication against a database,
not a file). So you create 50 connections for just logging in once -
surely that can't be right?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

auth:taglib and Turbine Connection Pool

Posted by Andreas Neuenschwander <an...@andi.ch>.
Hi,

I have a question about the auth:taglib.

Everything works well, but there is one thing I don't understand.

Why isn't it possible to use the Connection Pool from Turbine?

At the moment I must setup in the login.xml file the 

<connection>
    <driver>...<driver>
    <username>...<username>
    <password>...<password>
    <dburl>...<dburl>
</connection>

all these parameters.

Is it possible to use the Turbine Connection Pool for the auth:taglib too?


.andi




Re: util:include-uri authentication (+cookies & form data)

Posted by Ulrich Mayring <ul...@denic.de>.
Jesse Reynolds wrote:
> 
> Okay, how do I write my own logicsheet? Is it simply a matter of
> creating something like "myutils.xsl" and referencing it in
> cocoon.properties etc as a taglib? Or do I have to write a
> corresponding java file and copile it all somehow?

Better yet: put this in your xml file:

<?xml-logicsheet href="/path/to/myutils.xsl"?>

and declare the myutils namespace in the xmlns attribute of <xsp:page>

That way you don't have to modify cocoon.properties and restart cocoon
every time you change myutils.xsl

> If i wanted to try making modifications to the util logicsheet
> (taglib) would I be making changes to both
> 
> src/org/apache/cocoon/processor/xsp/library/java/util.xsl

Yes. Please contribute these changes.

> src/org/apache/cocoon/processor/xsp/XSPUtil.java

No, this is just a collection of "un-taglibbed" utility methods. You can
use them inside <xsp:logic> but they're not in any taglib.

> If so, I presume I'd have to remake cocoon yes? How do I do that?

build.sh on UNIX and build.bat on DOS generate a new cocoon.jar in
subdirectory build.

ULrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

Re: util:include-uri authentication (+cookies & form data)

Posted by Jesse Reynolds <li...@va.com.au>.
>
>>  >you can manipulate cookies for the current connection using cookie
>>  >logicsheet, though i think its design leaves something to be desired.
>>  >however, i don't know any way to attach cookies to the java.net http
>>  >client that's used by the util logicsheet. form data, that is to say
>>  >request parameters, you can tack onto the url:
>>  >
>>  >http://username:password@example.com/protected/resource?foo=bar&bar=bat
>>  >
>>  >via the get method. post method would be trickier, i'm not aware of
>>  >anything in the servlet or JDK API's to generate post requests - but using
>>  >a post here would be wrong anyway.
>>
>>  I need to do POST. Why do you think it would be wrong?
>
>POSTs are supposed to make changes server-side, and i think if that's what
>you're doing, that it should be called explicitly, rather than as just a
>side effect of including a resource. it's really your call though.

I believe I can include cookies and do POST as well as GET with the 
Java.net http client (java.net.HttpUrlConnection contains 
setRequestMethod, which can take 'post').

>
>  > So, for some requests (when performing site editing functions) we'd
>>  like to pipe the incoming request straight through cocoon and onto
>>  our external web app for it to decipher cookies etc, via both the GET
>>  and POST methods.
>>
>>  I hope this makes sense and gives a sensible reason for wanting to use POST.
>>
>>  Next question is for advice: what would be the best way of making
>>  this happen? Ie, by extending the util logicsheet, or by building our
>>  own taglib to do all this? Or something else again?
>
>if you really need to generate your own POST URL calls, you probably need
>to write your own logicsheet. if you're happy with what you come up with,
>you might consider submitting a patch to the util logicsheet.

Okay, how do I write my own logicsheet? Is it simply a matter of 
creating something like "myutils.xsl" and referencing it in 
cocoon.properties etc as a taglib? Or do I have to write a 
corresponding java file and copile it all somehow?

....

If i wanted to try making modifications to the util logicsheet 
(taglib) would I be making changes to both

src/org/apache/cocoon/processor/xsp/library/java/util.xsl

and

src/org/apache/cocoon/processor/xsp/XSPUtil.java

???

If so, I presume I'd have to remake cocoon yes? How do I do that?

Thankyou

-Jesse

-- 

       Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
                                                  jesse (at) va.com.au

Re: util:include-uri authentication (+cookies & form data)

Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 31 Jan 2001, Jesse Reynolds wrote:

> At 3:00 AM -0500 30/1/01, Donald Ball wrote:
> >On Tue, 30 Jan 2001, Jesse Reynolds wrote:
> >
> >>  Mika (or anyone else) Did you get this working?
> >>
> >>  As well as basic authentication, I also need util:include-uri (or
> >>  something else) to send cookies and form data...
> >
> >basic authentication you can possibly do by including the auth parameters
> >in the url:
> >
> >http://username:password@example.com/protected/resource
> >
> >otherwise you can mess around with the URL class methods for doing
> >authentication, it's not hard if i recall aright.
>
> Donald, where might I find documentation of the "URL class methods"?
> Or where would I find the source code for this? (Which file in the
> src)

http://java.sun.com/j2se/1.3/docs/api/java/net/package-summary.html

> >you can manipulate cookies for the current connection using cookie
> >logicsheet, though i think its design leaves something to be desired.
> >however, i don't know any way to attach cookies to the java.net http
> >client that's used by the util logicsheet. form data, that is to say
> >request parameters, you can tack onto the url:
> >
> >http://username:password@example.com/protected/resource?foo=bar&bar=bat
> >
> >via the get method. post method would be trickier, i'm not aware of
> >anything in the servlet or JDK API's to generate post requests - but using
> >a post here would be wrong anyway.
>
> I need to do POST. Why do you think it would be wrong?

POSTs are supposed to make changes server-side, and i think if that's what
you're doing, that it should be called explicitly, rather than as just a
side effect of including a resource. it's really your call though.

> Here's what we're trying to build... We have an existing web
> application produced with the 4D database environment, which handles
> things such as user registration, authentication, site construction
> and user submissions through forms. We want to 'wrap' it in cocoon,
> such that it just spits out xml and we use xsl in cocoon to format
> the html live etc, but retain the use of authentication via both
> basic auth and cookies, and form submissions for live editing of
> content. In this way cocoon could be thought of as a 'value added
> proxy server' for our application, providing one extra layer of
> abstraction.
>
> So, for some requests (when performing site editing functions) we'd
> like to pipe the incoming request straight through cocoon and onto
> our external web app for it to decipher cookies etc, via both the GET
> and POST methods.
>
> I hope this makes sense and gives a sensible reason for wanting to use POST.
>
> Next question is for advice: what would be the best way of making
> this happen? Ie, by extending the util logicsheet, or by building our
> own taglib to do all this? Or something else again?

if you really need to generate your own POST URL calls, you probably need
to write your own logicsheet. if you're happy with what you come up with,
you might consider submitting a patch to the util logicsheet.

- donald


Re: util:include-uri authentication (+cookies & form data)

Posted by Jesse Reynolds <li...@va.com.au>.
At 3:00 AM -0500 30/1/01, Donald Ball wrote:
>On Tue, 30 Jan 2001, Jesse Reynolds wrote:
>
>>  Mika (or anyone else) Did you get this working?
>>
>>  As well as basic authentication, I also need util:include-uri (or
>>  something else) to send cookies and form data...
>
>basic authentication you can possibly do by including the auth parameters
>in the url:
>
>http://username:password@example.com/protected/resource
>
>otherwise you can mess around with the URL class methods for doing
>authentication, it's not hard if i recall aright.

Donald, where might I find documentation of the "URL class methods"? 
Or where would I find the source code for this? (Which file in the 
src)

>you can manipulate cookies for the current connection using cookie
>logicsheet, though i think its design leaves something to be desired.
>however, i don't know any way to attach cookies to the java.net http
>client that's used by the util logicsheet. form data, that is to say
>request parameters, you can tack onto the url:
>
>http://username:password@example.com/protected/resource?foo=bar&bar=bat
>
>via the get method. post method would be trickier, i'm not aware of
>anything in the servlet or JDK API's to generate post requests - but using
>a post here would be wrong anyway.

I need to do POST. Why do you think it would be wrong?

Here's what we're trying to build... We have an existing web 
application produced with the 4D database environment, which handles 
things such as user registration, authentication, site construction 
and user submissions through forms. We want to 'wrap' it in cocoon, 
such that it just spits out xml and we use xsl in cocoon to format 
the html live etc, but retain the use of authentication via both 
basic auth and cookies, and form submissions for live editing of 
content. In this way cocoon could be thought of as a 'value added 
proxy server' for our application, providing one extra layer of 
abstraction.

So, for some requests (when performing site editing functions) we'd 
like to pipe the incoming request straight through cocoon and onto 
our external web app for it to decipher cookies etc, via both the GET 
and POST methods.

I hope this makes sense and gives a sensible reason for wanting to use POST.

Next question is for advice: what would be the best way of making 
this happen? Ie, by extending the util logicsheet, or by building our 
own taglib to do all this? Or something else again?

Cheers

Jesse

-- 

       Jesse Reynolds - Virtual Artists Pty Ltd - http://www.va.com.au
                                                  jesse (at) va.com.au

Re: util:include-uri authentication (+cookies & form data)

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 30 Jan 2001, Jesse Reynolds wrote:

> Mika (or anyone else) Did you get this working?
>
> As well as basic authentication, I also need util:include-uri (or
> something else) to send cookies and form data...

basic authentication you can possibly do by including the auth parameters
in the url:

http://username:password@example.com/protected/resource

otherwise you can mess around with the URL class methods for doing
authentication, it's not hard if i recall aright.

you can manipulate cookies for the current connection using cookie
logicsheet, though i think its design leaves something to be desired.
however, i don't know any way to attach cookies to the java.net http
client that's used by the util logicsheet. form data, that is to say
request parameters, you can tack onto the url:

http://username:password@example.com/protected/resource?foo=bar&bar=bat

via the get method. post method would be trickier, i'm not aware of
anything in the servlet or JDK API's to generate post requests - but using
a post here would be wrong anyway.

- donald