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.
Related
I spent a couple of hours to figure out why I'm not able to trigger a webhook from bitbucket to bamboo, I found nothing yet
Issue:
I want to track when a PR is merged or a branch is deleted which as I see I'm not able to track this stuff from bamboo, so I need to have a webhook in bitbucket and call a bamboo reset api base on this page if there is no better idea.
base on this page I thought I can trigger a webhook
https://confluence.atlassian.com/bamboo/triggering-a-bamboo-build-from-bitbucket-cloud-using-webhooks-873949130.html
But this solution is now working because each time I got this error message
{"message":"Anonymous user can't access this resource. If it should be available, modify anonymous user permissions at Administration > Security settings","status-code":401}
The only access we have for Anonymous group is view which I see this is not enough to call this API from bitbucket
https://confluence.atlassian.com/bamboo/bamboo-permissions-369296034.html
So I don't know what to do and how to track if a PR is merged or a branch is deleted.
I would appreciate to tell me what the problem is
FYI: bamboo and bitbucket version is the latest one
What is your Bamboo version? This issue was covered at Bamboo 6.7.0. At Bamboo > Administration > Security settings you can grant/deny access of anonymous users to given webhook
The easiest way is to enable triggers for anonymous users. Also, as #Hamed mentioned, allowing anonymous access is not feasible in some environments. The problem is we cannot even go with <User>:<Password>#<Bamboo URL> and that strips off the auth details.
One possible way of doing this is to keep a proxy between Bitbucket and Bamboo and then add the Authentication headers at the proxy level.
I'm using Nexus Repository Manager 3.1.0-04, and I want to create a user to just have deployment permissions. What are the minimal set of privileges required for that?
Right now I created a role nx-deploy with the following privileges:
nx-repository-admin---read
nx-repository-admin---browse
nx-repository-admin---delete
nx-repository-admin---edit
nx-repository-admin---add
Then I created a user deployment with the role nx-deploy. I can deploy artifacts now, however, I believe I am giving too much privileges? The admin part is not what I want the deployment user to be, so that part has me a bit nervous.
Needless to say, there are just too many privileges to choose from under the security section.
The general rule is nx-repository-admin privileges are for administering the repositories and their details; nx-repository-view privileges are for use of the repositories once set up. Assign the latter.
To tweak repository privileges of your Deployment user(s) you should use the nx-repository-view-*-*-* as the assigned privilege, instead of nx-repository-admin. So, remove all the privileges you addressed in your question, and replace the ‘Given’ field with nx-repository-view-*-*-*. Since the privilege is denoted with asterisks, your Deployment users can perform all the above actions (i.e. browse, read, edit, add, and delete).
See the screenshot for reference:
Configuring the nx-deploy Privilege for the Deployment Role
You can read more about Privileges in the Security chapter: https://help.sonatype.com/repomanager3/security/privileges
If you need minimal privileges to just deploy artifacts, nx-repository-view-*-*-edit is enough.
nx-repository-admin is used for administration and configuration
Repository Admin
These are privileges related to the administration and configuration of a specific repository
and edit is enough to modify repository content
edit
This action allows privileges to modify associated scripts, repository content, and repository administration.
BTW, you need nx-component-upload to upload components in web UI.
https://help.sonatype.com/repomanager3/user-interface/uploading-components
Successful deployment by maven 3 with Nexus 3.8.0 the following rights are required
nx-repository-view-*-*-edit
nx-repository-view-*-*-read
nx-repository-view-maven2-maven-snapshots-edit
nx-repository-view-maven2-maven-snapshots-read
"maven2"is recipe,"maven-snapshots" is your repository name.
I had upload jar to server, but I got below error. I had tried so many times.
And then I log into https://oss.sonatype.org/#stagingRepositories, I can see the list of Staging Repositories, but I cannot drop or release the repository. It said 403.
Could any one help me ? Thanks a lot.
Your account doesn't have permissions to perform these actions.
This isn't the right place to ask for help with this, file an issue at https://issues.sonatype.org in the "Community Support - Open Source Project Repository Hosting (OSSRH)" project.
I have installed Nexus 2.0.6 and the integration with my LDAP server is working (authentication only). Is there a way to configure Nexus so that only a set of developers are able to deploy a given artifact, or group?
I basically do not want a developer in Team A deploying an artifact that Team B is reponsible for.
You may partition a repository using repository targets, privileges, and roles as described in this Sonatype blog post. I tested this a few months back and it seemed to work well.
Under Nexus 2.0.1, this is the solution that I've worked through and verified.
Caveats:
This allows one to restrict the "Artifact Upload" option to a directory hierarchy.
This is not quite the same as "deploy" or in conjunction with "release prepare".
Steps:
Remove the single privilege of "Artifact Upload" from all that presently have it, that you do not want to have it.
Create the "Repository-Target" that includes the directory mask of where you want to give access. Ex. .*/com/mycompany/target-dir/.* Double check the mask, it starts with period-asterisk AND ends with period-asterisk.
Create the "Repository-Privilege" that maps to the Repository-Target you just created. Typically I include the repo-name in this repository-privilege-name, like "releases.com.mycompany.target-dir". This creates the CRUD entries (4) for said directory.
Next, create the "Role" based on the Repository Privileges you just created (4), plus "Artifact Upload". Total of 5 entries for the role. Use the "Apply Filter" here to help you find these items. I name this role something like "Upload.Role.Releases.Target-Dir". Again, when finished there should be 5 entries for this role:
Artifact Upload
com.mycompany.target-dir(create)
com.mycompany.target-dir(delete)
com.mycompany.target-dir(read)
com.mycompany.target-dir(update)
This is what constrains the upload role to this repo.directory.
Create the User if it does not already exist, assign password.
Give the user the following Roles:
Nexus Deployment
Repo: All Maven Repositories(Read)
UI: Base UI Privileges
Upload.Role.Relases.Target-Dir
Hit save and you've got it. Later on, you can use this same approach to create a new Role for other repos (say Snapshot or 3rd Party), and keep the same directory mask.
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