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]
