Hi there,
In your banking example, no information is given away by the URL itself.
Where I work, only authorised employees have access to certain Jenkins
jobs. Other people (e.g. contractors) should not even know that we're
working on certain products -- whose existence they would be able to
ascertain via URLs which return 401 rather than 404.
In any case, you can configure your web server to redirect 404s to the
home page, e.g. in the simplest case for Apache:
ErrorDocument 404 /
Regards,
Chris
On 03/02/2012 02:44 AM, terry.rank...@csiro.au wrote:
Hi Guys
I think this is a little bit of 'security through obscurity'. For that user it
is perfectly acceptable for them to go back to the URL they were at yesterday,
and if they are not logged in I BELIEVE it should ask you to do so.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes, and even teapot's seem
to have response codes.... lookup 418.
My example here is from my bank.... which should be a little paranoid about
security.
https://ibs.bankwest.com.au/CMWeb/ which is where they serve their personal
banking data from does not return a 404, it pushes me back to a login page.
Where in the codebase would I custom patch it to return not authorized or a
please logon instead of a 404?
Regards,
Terry
-----Original Message-----
From: jenkinsci-users@googlegroups.com
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Christopher Orr
Sent: Friday, 2 March 2012 7:57 AM
To: jenkinsci-users@googlegroups.com
Subject: Re: 404 vs 401
On 06/02/2012 01:49, terry.rank...@csiro.au wrote:
When a user logs out, closes the browser, and then reopens it (clean
start) and loads a bookmark of a project URL which is valid, he gets a
404 (not found) instead of a 401 (not authorised).
I don't think that this is really the right behaviour, I would suggest
using the 401, or redirecting it to the top level login.
AFAIK, this is a security feature -- i.e. by returning 404 no
information is leaked to unauthorised users about the existence or
non-existence of any given job.
But in any case, a nicer-looking error page could be good -- though I'm
not sure whether Jenkins can directly solve this given that the
underlying web server is presumably the one handling the 404s.
Regards,
Chris
