2010/9/2 Marcin Zajączkowski <[email protected]>
> Dnia 2-09-2010 o godz. 12:08 Yoav Landman napisał(a):
>
> I don't think 403 is going to help in this case, since you want maven to
> respond to an auth challenge which will only happen for a 401.
>
>
> I'm not sure what point you are writing about. If about RTFACT-3479 then
> Yossi wrote about 401 for anonymous user when flag is checked, so it should
> work in my case.
>
>
I assumed you referred to the original discussion and issue that still refer
to 403. I will update the issue title.
> We will add a new flag to the general security settings. When checked
> (default), if the user is not authorized to download the resource
> Artifactory will return 401+request for basic authentication if anonymous
> and 403 if not anonymous. When the flag is not checked, will return 404.
>
>
> When about my problem with preemptive authenticationthen then I though that
> Maven with http.authentication.preemptive set on true should send
> credentials with every request to configured server, but maybe I
> misunderstood that mechanism?
>
That is indeed the expected behavior but the mechanism seems to be broken,
also according to our tests.
>
>
> Regards
> Marcin
>
>
>
>
> 2010/9/1 Marcin Zajączkowski <[email protected]>
>
>> Dnia 1-09-2010 o godz. 0:26 Yoav Landman napisał(a):
>>
>> <http://../>This behavior is "by� design". Let me explain -
>>
>> When� anonymous� access is� disabled� Artifactory always requires
>> users to be authenticated. This is the meaning of the flag, which is checked
>> whenever� an unauthenticated request is seen.
>> If an� unauthenticated� request arrives, the anonymous access flag is
>> on and the resource exists but is not accessible by anonymous - Artifactory
>> will correctly log the request as DENIED, but� for security reasons it
>> will not reveal the existence of the resource to the requestor and will send
>> back a 404. This behavior matches the 404
>> description<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>:
>> "...This status code is commonly used when the server does not wish to
>> reveal exactly why the request has been refused...".
>> The result should be the same for a non-anonymous user that doesn't
>> have� privileges to get a resource (if not that's a bug).
>>
>>
>> Ok, I see some sense it that behavior - to protect knowledge about
>> (non)existing artifacts in a repository.
>>
>>
>> Like Yossi suggested, it can be resolved on the Maven side by setting
>> preemptive authentication.� Maven does not authenticate� preemptively
>> when provided with user/password details� unless configured to do so (for
>> why and how to configure it, please see:
>> http://maven.apache.org/guides/mini/guide-http-settings.html). The
>> reasons seem to be rooted in mistrusting the user
>> to� correctly� configure the client and the server - leaving behind
>> unused authentication details or sending authenticated requests to servers
>> that are not configured to secure the authentication details. Other tools
>> (Ivy, curl, wget) will authenticate� preemptively when provided with
>> authentication info.
>>
>>
>> Preemptive authentication should be helpfull and I tried to set it up, but
>> I wasn't able to force my Maven client to send credentials for the first
>> time to given server. Following configuration doesn't work - in Artifactory
>> log I see only one try to download file as anonymous user. Maven 2.2.1,
>> Windows. Maybe you have some idea what could be wrong here?
>>
>> Â Â Â Â Â <server>
>> Â Â Â Â Â Â Â Â Â <id>repo-id</id>
>> Â Â Â Â Â Â Â Â Â <username>user</username>
>> Â Â Â Â Â Â Â Â Â <password>pass</password>
>> Â Â Â Â Â Â Â Â Â <configuration>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â <wagonProvider>httpclient</wagonProvider>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â <httpConfiguration>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <put>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <params>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <param>
>>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
>> <name>http.authentication.preemptive</name>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <value>%b,true</value>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â </param>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â </params>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â </put>
>> Â Â Â Â Â Â Â Â Â Â Â Â Â </httpConfiguration>
>> Â Â Â Â Â Â Â </configuration>
>> Â Â Â Â Â </server>
>>
>>
>> On the Artifactory side this can be resolved by a global policy of
>> whether or not to reveal the existence of protected resources.
>> For� anonymous� requests that will result in a 401. Anyway, please
>> follow� RTFACT-3479 <http://issues.jfrog.org/jira/browse/RTFACT-3479>� to
>> check on the progress.
>>
>>
>> Solution proposed by Yossi should resolved my problem completely. I'm
>> impatiently waiting for a first nightly build with that feature to test it.
>> Thanks guys for your commitment.
>>
>>
>> Best
>> Marcin
>>
>>
>> 2010/8/31 Yossi Shaul <[email protected]>
>>
>>> I see what you mean. I think 403 Forbidden will be more appropriate in
>>> that
>>> case because access to Artifactory is always authenticated (when
>>> anonymous
>>> is enabled the authentication is implicit).
>>> I can't remember if the 404 response is for historical reasons (old maven
>>> bug), so I opened
>>> an issue (http://issues.jfrog.org/jira/browse/RTFACT-3479) and will look
>>> into it soon.
>>>
>>> Back to your problem, your analysis explains why it fails:
>>> You are implicitly logged in as anonymous to Artifactory. Anonymous
>>> doesn't have read access
>>> to the requested file and Artifactory sends 404. When maven receives 404
>>> it will never try to send
>>> another request with credentials.
>>> Responding with 401 Unauthorized (+the basic authentication header) will
>>> probably solve it,
>>> but again, I'm not sure this is the best solution.
>>>
>>> In the mean time you can configure maven to use preemptive
>>> authentication, which causes
>>> it to send the credentials without being asked to.
>>>
>>> Yossi
>>>
>>> 2010/8/31 Marcin Zajączkowski <[email protected]>
>>>
>>> Dnia 31-08-2010 o godz. 9:22 Yossi Shaul napisał(a):
>>>> > Which version of maven you are using? If it's not the latest (2.2.1 or
>>>> 3
>>>> beta) please try with one of them.
>>>> > Otherwise send your pom and settings to [email protected] and we'll
>>>> try
>>>> to figure out what's wrong.
>>>>
>>>> I'm using 2.2.1, but I have noticed one more thing. With disabled "allow
>>>> anonymous access" artifactory return 401 Authorization Required in the
>>>> first try and then Maven ask again using credentials [1]. Without
>>>> anonymous access enabled Artifactory returns 404 Not Found (even if
>>>> artifact is in repository and only anonymous doesn't have access to it -
>>>> in access.log there is DOWNLOAD DENIED) and Maven doesn't try again,
>>>> what could be a reason.
>>>>
>>>> Maybe Artifactory could return 401 for repository paths which requires
>>>> for user to be authenticated?
>>>>
>>>>
>>>> [1] - (with "allow anonymous access" disabled)
>>>>
>>>> 20100831113125|0|REQUEST|10.101.6.191|non_authenticated_user|GET|<<artifact>>|HTTP/1.1|401|0
>>>>
>>>> 20100831113127|1656|REQUEST|10.101.6.191|my_user|GET|<<artifact>>|HTTP/1.1|200|348
>>>>
>>>>
>>>> Marcin
>>>>
>>>
>>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Ad...
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
