[SecurityHeaders] Added a possibility for no follow redirects

[mbogh]

Added a possibility for no follow redirects on Security Headers badge like:

The naming of the parameter is a bit reverse but could not figure out if it is possible introduce a new parameter without breaking existing badges.

fixes #6211

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @mbogh!

Generated by 🚫 dangerJS against fc0dd32

[calebcartwright]

The naming of the parameter is a bit reverse but could not figure out if it is possible introduce a new parameter without breaking existing badges.

Yeah that does make it feel a bit awkward. I suppose another way would be to just have followRedirects as the badge url query param, with the values confined to true and false and the default set to true. That won't play quite as nice in the badge builder window on the Shields.io site (instead of a checkbox it'd have a text box that would require typing the literal true or false) but it makes for a more natural query param IMO.

cc @badges/shields-maintainers for any other perspectives, I'm a little torn myself

[PyvesB]

I suppose another way would be to just have followRedirects as the badge url query param, with the values confined to true and false and the default set to true. That won't play quite as nice in the badge builder window on the Shields.io site (instead of a checkbox it'd have a text box that would require typing the literal true or false) but it makes for a more natural query param IMO.

Personally I would favour having noFollowRedirects with the simple UI behaviour rather than having followRedirects with true/false. Alternatively, we could word things as ignoreRedirects, at the cost of losing the verb "follow" which is commonly used in the context of HTTP redirects.

[chris48s]

I think I'm for noFollowRedirects too 👍

In general the way we do boolean params is presence in the qs means true, so maintaining that consistency is useful

Also, the current default is probably the behaviour most users want for this badge so I think it makes more sense if the route most people want is /security-headers not /security-headers?followRedirects=true. I'd think of this as analogous to the JIRA disableStrictSSL param.

[calebcartwright]

I think it makes more sense if the route most people want is /security-headers

That would still be the case, the absence of the query param would still result in redirects being followed.

I don't feel too strongly about this one though, just something about noFollowRedirects is tough for me 😄. I think I'd be more okay with that if the name was changed to something like ignoreRedirects as @PyvesB suggested, or skipRedirects etc.

[chris48s]

ignoreRedirects or disableRedirects also works for me 👍

[calebcartwright]

Sounds like ignoreRedirects is the winner then. @mbogh could you update the param name when you get a chance? The rest LGTM.

Also just out of curiosity, what does a rating of R correlate to? Hopefully this isn't a scale that runs from A through at least R 😄

[mbogh]

@calebcartwright R is just means Redirect, at the company I work, all services are scanned with various tools and scored on different parameters, and a recent service I made simply redirects to other places, so instead of seeing a SH score of e.g. B, I wanted the true score of R to be displayed on the repo.

I will make the changes to ignoreRedirects.

[calebcartwright]

R is just means Redirect, at the company I work, all services are scanned with various tools and scored on different parameters, and a recent service I made simply redirects to other places, so instead of seeing a SH score of e.g. B, I wanted the true score of R to be displayed on the repo.

If R is just an informational reflection of the fact that it redirects, as opposed to a position in a tiered scale like the others, I wonder if our default badge color for informational message wouldn't be better than the lightgrey (which we use to convey things along the lines of "inactive").

I similarly don't have strong opinions on this one so will go ahead and approve, but will hold off on merging in case others have different views

clicked too fast