In the past I was able to prevent Anonymous (Anyone group?) user from viewing sourcecode on projects (6.2) - Now with 6.4 I cannot

[Sherlock]

In 6.2, through project permission I could prevent anyone but logged in folks to see source code.

Upgrade to 6.4 with the new public/private project setting set to public, unchecking "view source code" in the permissions default template and leaving "Browse" for the anyone group has absolutely zero affect on an anonymous person browsing the sonarqube page.  Removing all permissions in the template did nothing as well.

I applied the template to all of my projects through the "bulk apply" method.

Now the reason I had to do this in the first place was because I am using the SVG Badges Plugin from QualInsight and there is no way to make the badges public if I restrict users to where they always have to log in - nor is there a method at the moment to keep the badges public if the the project is set to private.

So I guess what I am saying applying permissions to the "Anyone" group makes zero difference if the project is public. 

Is there a way around this?

Thank you

[G. Ann Campbell]

Hi,

Go to project-level permissions administration and you'll see that the ability to toggle Browse and See Source Code for any group (including Anyone) is simply not available for Public projects because the definition of a Public project is that every user can Browse and See Source Code.

Conversely, make your project private, and you can set Browse and See Source Code permissions. However, you cannot grant Anyone permissions on a private project.

I think your best course will be to make the project private and grant Browse to the sonar-users group. It means your folks will have to log in, but otherwise should accomplish what you're after.

Ann

[Sherlock]

I understand what you are saying, however - there is no way to protect source code from being viewed by "Anyone" and make the SVG badges available publicly - and I was able to do this in previous 6.* versions. So there was something lost upon public/private addition in 6.4. It seems to be a pretty deep seated issue - this "Anyone" group permissions this and anonymous users so I get that, but I think the philosophy is flawed if an administrator cannot manipulate all groups and all users. Right now, at least how I see it there is no purpose in letting anyone know that there even is an anyone group - to me it seems superfluous if it cannot be manipulated.  It may be true that the operating assumption of the definition of a "Public Project" for you is "browse and see source code," however there used to be a way to make the results public but not the source and that is an important distinction.

All of that would be moot in my case if there were a way to allow certain urls to be public without authentication in the server config.

I hope the product/dev teams reconsider this permissioning/auth model. I think it is ham-stringing the application. 

At any rate, I appreciate your time, but I am going to roll back to an earlier version unless someone else has any ideas. Thank you.

[Fabrice Bellingard]

Hi,

IMO, your point should not be restricted to the SVG badges. If you want anonymous access to SVG badges for a private project, this means that measures of that project must be accessible anonymously. Otherwise, this means that you're making a special case for that plugin - which we don't want to not introduce security weaknesses.

So now the question is: should measures (amongst other things) of a private project be accessible to *anonymous* users? I tend to think that the answer is no. "private" means access restricted to known users (and groups) - otherwise you don't master who can view what which is not great in terms of security.

Still, you're raising 2 points that are true:

• "Anyone" group is still accessible. 
• This is simply because we couldn't get rid of it in this iteration. But we definitely want to get rid of this "virtual" group that has been annoying us for years (because it kind of mixes the concept of "all users" and "anonymous" users).
• And because it's still here for the moment, you're right this is misleading.
• It was possible in previous versions to have a project that anonymous users can look at (measures, issues, folder/file names, ...) without being able to actually see the code
• The impact is that now users will have to log in to see information (measures, badges and so on) of your private project - which (again) makes sense to me in terms of security because you control who has access to your project

Hope all this makes sense,

Best regards,

Fabrice Bellingard | SonarSource SonarQube & SonarCloud Product Manager http://sonarsource.com

The information contained in this email may be confidential. It has been sent for the sole use of the intended recipient(s). If the reader of this email is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender immediately and destroy all copies of the message.

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/74d32575-7d61-4156-9a0a-145b042f84cd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sherlock]

If you have a private project in github (plug in the name of any third party app here if you don't like github), and you want to show badges on the github readme doc(landing page) for that repo you cannot do this unless the project is public in SonarQube. Once you require a login the badges are not accessible by github. Badges are for display else ware on a third party application/page - if they cannot be displayed else ware while maintaining code security they make no sense to have at all.  This is the use case for public results and private code/projects.

Badges make no sense unless they can be made public or have a way to auth a 3rd party app to gain access to them. If this auth method exists I would very much like to know about it.

Thank you for taking the time to respond I do appreciate it.

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

[Fabrice Bellingard]

On Mon, Jun 12, 2017 at 6:29 PM, Sherlock <hank....@meltwater.com> wrote:

If you have a private project in github (plug in the name of any third party app here if you don't like github), and you want to show badges on the github readme doc(landing page) for that repo you cannot do this unless the project is public in SonarQube. Once you require a login the badges are not accessible by github. Badges are for display else ware on a third party application/page - if they cannot be displayed else ware while maintaining code security they make no sense to have at all.  This is the use case for public results and private code/projects.

Badges make no sense unless they can be made public or have a way to auth a 3rd party app to gain access to them.

If you take a look at how they do that at Travis CI, they require that you pass a token when the repository is private:

https://travis-ci.com/MyOrg/my-repo.svg?token=dsh3090kjdkf090J&branch=master

To me, this is aligned with what we're doing: when a project is private, you've got to authenticate to access its information.

 

If this auth method exists I would very much like to know about it.

You can probably achieve something similar to what's done @Travis the following way (I haven't tested though):

1. Create a "technical user" (hope you can)
2. Generate a token for this user
3. Grant this user the "Browse" permission on your private project(s)
4. Use the following URL to refer to the badges: 
• https://<user_token>:@<your_instance>/api/badges/gate?key=<project_key>

Note that we want to develop this badge feature as a built-in core feature in the near future (because by definition, plugins have a limited access to what they can do). We'll make sure that this works smoothly.

Thank you for taking the time to respond I do appreciate it.

And thank you for giving feedback, we also do appreciate!

 

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5ecbba62-bf22-4450-b6ee-38bc36a85a04%40googlegroups.com.

[Sherlock]

As far as I can tell the following method you mentioned does nothing - blank page.

Use the following URL to refer to the badges: 

• https://<user_token>:@<your_instance>/api/badges/gate?key=<project_key>
  

so I can type in the following (token and name of resource have been changed)

https://ab12c34567890123d4e5fa6bcd7e8f90a1b2c34d@:mydns.pos//api/badges/gate?key=hello.world

and I get a blank page

[hankq...@gmail.com]

Revised to request to look like the following by adding  the username after the colon
https://ab12c34567890123d4e5fa6bcd7e8f90a1b2c34d:myuse...@mydns.pos/api/badges/gate?key=hello.world
I get a redirect to a badge but the badge has no access to proper information.  When logged in I get a green "Pass". when I just try to use the token as described it becomes "Not found"

[alvara...@gmail.com]

Would love to see this get a bit more attention as I run a secured instance where my GitLab users would be signed in to GitLab but not onto SonarQube -- and therefore not being able to see badges, ie.

I do have an OAuth provider that links my SonarQube login process with GitLab, but once their session is over, they'll need to sign in again to access SonarQube.

While the cURL method is the documented example (not the best approach for a Markdown document), I would love for SonarQube to take the Travis CI approach of passing tokens as an URL argument.

Has the above been given consideration?

[G. Ann Campbell]

Hi,

You can follow this ticket: https://jira.sonarsource.com/browse/MMF-914 to see any progress. Since the ticket type is currently "idea", it means that it's something we're thinking about, with no commitment whatsoever. 

Ann

[alvara...@gmail.com]

Thank you Ann for the reply and the link to the issue tracker as well.

I'm currently using nginx to proxy badge requests for now, but seeing plans in motion to make this an integrated feature is an awesome thing to look at.