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.

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?


Regards
Marcin




2010/9/1 Marcin Zajączkowski <[email protected]>

Dnia 1-09-2010 o godz. 0:26 Yoav Landman napisał(a):

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: "...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� 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

Reply via email to