Hi Jonathan,
Did you solve your problem?
Earlier you asked if you could send two requests, one to log in and another
to download the stuff. You absolutely can as this is how browsers work.
You just need to keep the session id that tomcat sends back in the header
once you log in and resend it in the header with your new request to
download. Tomcat can't tell and doesn't care what kind of client you are
using. I have done this before to make a mass upload desktop tool for a
webapp that only let users upload photos one-at-a-time.
I've never used wget so the next question is can you use wget with custom
headers? Googling real quick I found you can tell wget to save the cookies
like this:
wget --keep-session-cookies --save-cookies login.txt PAGE-URL
Since it lets you save the cookies, I'm sure there's a way to use the
cookies again...
If you don't want to do that and you are still having problems you could do
your own authentication rather than container-based. I mean let all
requests come through as far as Tomcat is concerned but then validate
against a session var in your webapp. Then you can set up your app to check
for GET vars as well as POST vars (ie. check with
request.getParameter("...") too). Try JPetStore 3 by Clinton Begin
(www.ibatis.com) as a reference if you've never done this before. I haven't
tried version 4 yet so don't know if it uses container-based authentication
or not.
hth,
Adrian Lanning
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Monday, March 22, 2004 7:21 PM
Subject: Re: Login by parameters (no prompts)
> > I don't think so. The server doesn't care what is requesting the file
> > (wget, curl, lynx, Mozilla, Netscape, IE, etc, ...) -- just as long as
> > it's a valid request. Your options are still open there.
>
> This is true. Although the means of getting the username and password
> into the request is the crux of the problem. That is where I need a
> solution. If you are saying that every client will have its own method of
> achieving this, then I agree. Except that we still haven't established
> that Tomcat will handle it properly using FORM authentication.
>
> > What you might actually be looking at is designing an app to take a
> couple of
> > authentication methods (basic & form) depending on the client and just
> > send back the file.
>
> Are you suggesting a second web container that will only handle
> programmatic downloads? I don't think that the company will go for that
> solution. If this is not your suggestion, then I assume we are talking
> about configuring Tomcat to handle both types (FORM and BASIC) at the same
> time. I haven't figured out how to do that.
>
> Thanks for all the time you're putting into this. I appreciate it.
> Jonathan.
>
>
>
>
>
> David Smith <[EMAIL PROTECTED]>
> 03/22/2004 04:19 PM
> Please respond to "Tomcat Users List"
>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> cc:
> Subject: Re: Login by parameters (no prompts)
>
>
> I don't think so. The server doesn't care what is requesting the file
> (wget, curl, lynx, Mozilla, Netscape, IE, etc, ...) -- just as long as
> it's a valid request. Your options are still open there. What you
> might actually be looking at is designing an app to take a couple of
> authentication methods (basic & form) depending on the client and just
> send back the file.
>
> As far as wget is concerned, take a look at the man pages for it or even
> curl. Corporate policy shouldn't prohibit it given it does the same
> thing your Netscape or IE is doing, but then again all my work
> experience is at a university. I have no idea what a corporate
> environment would be like. I'm not a student - those lucky dogs are on
> Spring Break now :-(.
>
> --David
>
> [EMAIL PROTECTED] wrote:
>
> >Yeah, that might work (we'd have to test it). However, this implies that
>
> >we tie ourselves to WGET as a client app, which we cannot do. The
> >customer controls his own infrastructure and may not have WGET (he might
> >be on one of the many Windows platforms out there) or may have a
> corporate
> >policy that prohibits the use of WGET. The same is true of any possible
> >client app. They may even have written their own solution for polling
> the
> >downloadable data (as I've seen done in the past).
> >
> >*sigh* The best solution would be to authenticate and download in a
> >single request. But how?
> >
> >Thanks.
> >Jonathan.
> >
> >
> >
> >
> >
> >David Smith <[EMAIL PROTECTED]>
> >03/22/2004 03:04 PM
> >Please respond to "Tomcat Users List"
> >
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > cc:
> > Subject: Re: Login by parameters (no prompts)
> >
> >
> >I was just looking through the man page for wget. It looks like you
> >have the option of using --http-user=... and --http-passwd=... on the
> >command line. Wget will use BASIC or Digest depending on what the
> >server wants. Is that anything you might be able to use?
> >
> >--David
> >
> >[EMAIL PROTECTED] wrote:
> >
> >
> >
> >>Generally, David, I would agree with you about the presence of passwords
>
> >>in URLs. However, our product is an appliance that sits within a
> >>customer's trusted network and uses HTTPS for most of its sensitive
> >>communications (and this would certainly qualify as one of those cases).
> >>
> >>Another point to throw into this discussion: would it be possible to
> send
> >>
> >>
> >
> >
> >
> >>two requests - one to login (direct to j_security_check) and the other
> to
> >>
> >>
> >
> >
> >
> >>perform the intended action (i.e, downloading files)?
> >>
> >>If we can't find a way around this issue, then we may have to change our
>
> >>spec.
> >>
> >>Thanks for all the feedback.
> >>Jonathan.
> >>
> >>
> >>
> >>
> >>
> >>David Smith <[EMAIL PROTECTED]>
> >>03/22/2004 02:36 PM
> >>Please respond to "Tomcat Users List"
> >>
> >> To: Tomcat Users List <[EMAIL PROTECTED]>
> >> cc:
> >> Subject: Re: Login by parameters (no prompts)
> >>
> >>
> >>Hi.
> >>
> >>Time to go from lurker to contributer:
> >>
> >>Ummm.... that's not conformant to RFC spec and it's being discontinued
> >>in IE (90+% of your clients right there). I wouldn't recommend putting
> >>username/password info in the URL anyway.
> >>
> >>-David
> >>
> >>Jacob Kjome wrote:
> >>
> >>
> >>
> >>
> >>
> >>>Well, if it were BASIC Auth, then you'd just do this (over SSL, of
> >>>
> >>>
> >>>
> >>>
> >>course, to
> >>
> >>
> >>
> >>
> >>>hide the clear text username/password)...
> >>>
> >>>https://myusername:[EMAIL PROTECTED]
> >>>
> >>>If the username and password are valid, there will be no prompt for
> >>>
> >>>
> >>>
> >>>
> >>username or
> >>
> >>
> >>
> >>
> >>>password. You'll get right to the resource.
> >>>
> >>>Jake
> >>>
> >>>Quoting [EMAIL PROTECTED]:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>The application we are building allows file downloads from our UI.
> >>>>However, we also want users to be able to download these files using
> >>>>
> >>>>
> >>>>
> >>>>
> >>WGET
> >>
> >>
> >>
> >>
> >>>>from a command-line (perhaps as part of a script), like this:
> >>>
> >>>
> >>>
> >>>
> >>>> WGET 192.168.1.1/do/download?id=1
> >>>>
> >>>>However, these file downloads are subject to authentication and should
>
> >>>>
> >>>>
> >>>>
> >>>>
> >>be
> >>
> >>
> >>
> >>
> >>>>restricted to certain user roles.
> >>>>
> >>>>We have already implemented a JDBCRealm and everything works very well
> >>>>within the UI. The problem is that we can't figure out how to get
> >>>>
> >>>>
> >Tomcat
> >
> >
> >>>>to invoke authentication without a prompt. At first, we thought that
> >>>>adding "j_username" and "j_password" as part of the URL might do the
> >>>>trick. No such luck. We looked through the documentation and
> couldn't
> >>>>find any suggestions (unless we missed something along the way).
> >>>>
> >>>>What we want to be able to do is have the user provide the username
> and
> >>>>password as part of the URL, like this:
> >>>>
> >>>> WGET 192.168.1.1/do/download?id=1&username=bob&password=secret
> >>>>
> >>>>I know that we could always extend Tomcat with our own code, but I'd
> >>>>really like to avoid having to do that. I haven't been allowing any
> >>>>platform-specific code into the product and I don't want to start now.
>
> >>>>
> >>>>
> >>>>
> >>>>
> >>The
> >>
> >>
> >>
> >>
> >>>>use of a JDBCRealm was a compromise that was supposed to reduce the
> >>>>
> >>>>
> >>>>
> >>>>
> >>coding
> >>
> >>
> >>
> >>
> >>>>effort. Please tell me that there is a way around this issue that
> >>>>
> >>>>
> >>>>
> >>>>
> >>doesn't
> >>
> >>
> >>
> >>
> >>>>require coding Tomcat extensions.
> >>>>
> >>>>Thanks for any help you guys might be able to give me.
> >>>>Jonathan.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
