I have problems with configurations using Maven + Artifactory.
I try to download a new external file using a user created in Artifactory and my Artifactory doesn´t make download, claiming "Access denied" but if I put the same credentials as defined in remote settings, my application can download every external jars.
If I use the same permission setting of my remote configuration settings.xml where the Artifactory was installed (user admin) I can make downloads quickly.
There´s some way to configure to create a user in my Artifactory and configure the permission to make downloads of new artefacts? Because I didn´t find in anywhere.
I think that is more secure for my company if I have the possibility to create a new user in my Artifactory and just give the permissions: read and to download new artefacts but this option doesn´t exist in Artifactory.
How could I do this?
Because you've created a user entity within Artifactory, make sure it's got at least read permissions on all the repositories you'd like to resolve from.
For easier Maven configuration, you can also use Artifactory to generate proper Maven settings for yourself; this helps to reduce typos and reference mistakes (make sure you're logged in as the user entity you've created whilst generating the settings). After applying the settings file you can also run the mvn help:effective-settings goal on your project to make sure everything was applied correctly.
Finally, if you're required to authenticate with the remote repository you're proxying, you'll need to he specify the credentials in the configuration of that remote repository.
Make sure the user you are using to connect to Artifactory has Deploy permissions in Artifactory. The Deploy permission allows the user to download artifacts from repositories (in other words, populate cache with remote artifacts).
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions
Deploy Allows deploying artifacts and deploying to caches (i.e.
populating caches with remote artifacts)
More information from the JFrog forum:
http://forums.jfrog.org/Maven-using-anonymous-user-even-though-artifactory-server-setup-in-the-settings-xml-td4634521.html
Related
I'm having issues when I build my project using Maven and it attempts to download an artifact from my privately hosted Artifactory repository. I have a large number of artifacts used by my project that are stored in this Artifactory instance. It downloads many of them fine during the build process, but when it gets to the org.apache.solr SOLRJ artifact download, it fails with a "401 Unauthorized" error.
I know my configurations in my Maven project POM file and my local Maven settings file are correct (repo ID matches, username and password entered, etc.) because it successfully downloads the first half of the artifacts referenced in my project and only fails when it gets to the SOLRJ artifact. In addition, when I navigate to the repo in a browser window, I can freely navigate the tree and view other artifacts without providing credentials, but when I try to click on the link for the org.apache.solr folder, it prompts me for credentials and none of my known credentials work, even though I know the username and password are correct. So it seems the issue is isolated to this one artifact.
I have copied the org.apache.solr contents from another local repository to attempt to get it to skip downloading the file, but it is still trying to download even though it would appear the version is correct and matches.
I am confused why, when navigating the repo in the browser, this one folder in the repo would be prompting for authentication when no other artifacts are behaving the same way, and why none of my username/passwords entered (including the administrator username/password) are being recognized and accepted.
Any help is greatly appreciated to either a) point me in the right direction to make that artifact behave like the others and not require a username/password, or b) get my build to recognize that I've already got the files in the local repository so it doesn't need to download them again.
I am deploying artifacts to jfrog Artifactory in cloud which is throwing unauthorized for few artifact deploy but not for others.
Did anyone face similar issue?
Also, I would like to check if there is a way to restore initial Artifactory user permissions as I made some changes with permissions and now I do not see many options (not able to create users, groups,repositories, couldn't see default repositories) which were there initially.
Can someone advice how to restore default settings for this user?
Below are the answers to your questions.
I am deploying artifacts to jfrog artifactory in cloud which is throwing unauthorized for few artifact deploy but not for others.
Did anyone face similar issue?
Answer: Its wired, if a user is having permissions to the particular repository to deploy, then the same user can deploy any artifacts to the repository until and unless an include/exclude pattern is set at the repository level.
Further details can be found here.
I would like to check if there is a way to restore initial artifactory user permissions as I made some changes with permissions and now I do not see many options(not able to create users, groups,repositories,couldnt see default repositories) which were there initially.
Can someone advice how to restore default settings for this user?
Answer: As its a cloud instance, so we will not have any control over restoring the users permission to previous state. If it was a on-prem instance then it could be achieved by restoring from the backup. You can reach out to JFrog Support cloud team and check if they can help you with it.
If you remember the previous permissions the user then you can login with the admin user and set it, Else the other option is to create a new user with required permissions.
Relevant setup information: gradle 4+, relatively new installation of Artifactory (Pro 6+), artifactory gradle plugin version 4+
When attempting to run the build command on a local development environment in both Eclipse Photon and IntelliJ (late 2017 version), I run into dozens and dozens of 403 errors when making a HEAD request for dependencies. But, if I login to Artifactory through a web browser as the user that gradle is using and go to the exact same URL, it has no problem reaching the resource that gradle failed to reach. The problem occurs with every user on Artifactory, even one with admin privileges. The jars I'm looking for are part of a virtual repository with dependencies both internal to the artifactory installation and external. Finally, the build used to work just fine a month ago, and nothing I can think of has changed to permissions.
tl;dr only when logging in from gradle and using Artifactory plugin, a virtual Artifactory repo returns 403 errors on nearly every dependency for every user
This question: Docker pull from artifactory fails with credentials issue seemed close, but is using docker+jenkins (I'm not) and has no answers.
When I finally dug into the system logs, I found many lines like this one: "Rejected artifact download request: User XYZ is not permitted to deploy 'SOME JAR' into 'SOME CACHE JAR'"
It appears that users must have DEPLOY permissions in order to download an artifact that will be cached (behavior of virtuals/remotes.) This may also explain why the build used to work - the cached jars wouldn't have needed updates a month ago when I'd just added the remote and downloaded everything.
Adding deploy permissions to my user for the relevant repositories fixed the issue.
We are looking into setting up a local maven repository server at our institute. We have several teams that are completely independent and therefore should not have write access to each others artifacts.
Ideally we would like a similar permission concept as e.g. Gitlab, where every user can create a project (or in this case repository) and give permissions to it, but not have write access to any other repositories.
I tried out Artifactory and Nexus, but as far as I could tell, giving permissions to a group for a specific project includes manual work for a user with full admin rights, namely creating that repository.
Is there a freely available maven repository server, that allows creation and administration of repositories by users without giving them access to other repositories? If not, is there one, that can restrict write access for an artifact to the person who first deployed it?
Even better if Artifactory or Nexus can in fact do something like that and I just missed it.
You can create an arbitrary number of repositories in one Nexus 2.x (professional) server. Then you can set up different user accounts with different writing rights, e.g. you can create a projectA repository and define a projectAuser which has writing rights only for this particular repository.
I guess this is possible in Artifactory and Nexus 3 as well, but I do not have experience.
In Artifactory you have many options, I recommend you:
Create a virtual maven repository with permissions for a group of users.
Configure the settings.xml of this group of users with this virtual repository.
Create remote repositories to access to Github or any other websites.
Add these remote repositories to the virtual repository.
Create local repositories if you need and add to the virtual repository.
Do this with every group of users that you want and you will have independent artifacts and repositories.
We use Artifactory for our company's Maven repository. Is there a way to set it up (or set Maven up) so that an artifact can't be deployed to the repository if there is a pre-existing artifact with the same version number?
The reasoning for this is to make sure that valid releases don't accidentally get overwritten. If an artifact really does need to be re-deployed, one of our developers can use the Artifactory web interface to delete it. Then they can deploy the new copy.
Thanks!
This is easily achieved by revoking the "Delete" permission from the deploying users\groups on the target repository; the delete permission is required for both artifact removal and artifact re-deployment.
All user\group permissions are editable within the UI at Admin->Security->Permissions.
Also see Managing Permissions