log in after accessing a protected bug is a two step process

NEW
Unassigned

Status

()

--
enhancement
12 years ago
12 years ago

People

(Reporter: froh, Unassigned)

Tracking

({ue})

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-9.5 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-9.5 Firefox/1.5.0.3

try to access a bug that requires to be logged in while not logged in.

this brings up a message that to access this bug you need to be <a ...>logged in</a> to access this bug.

following the link gets you to the log-in screen.

that log in then gets you to the defect proper.


proposal:

inform the user htat he has to log in and allow the user to provide his credentials in the same dialogue / page.  Do not require a mouse click to get to the log in page and another one to perform the log in but do it One Click.

Reproducible: Always

Steps to Reproduce:

preparation: log out
1.try to access an access controlled bug you need to login for:
   https://bugzilla.mozilla.org/show_bug.cgi?id=DONT_HAVE_AN_EXAMPLE
2.get the redirect page, follow the link
3.get the log in page, provide credentials
4.get the bug

Actual Results:  
access the access controlled bug in four steps with two clicks.

Expected Results:  
have a login: and password prompt on the page telling you that you need to log in.

succesfully login with one click.

access the access controlled bug in three steps with one click.


I experienced that on the Novell bugzilla instance bugzilla.novell.com and was told that this workflow was untouched from the generic bugzilla and I should report here.

Comment 1

12 years ago
indeed.

one question though. suppose any of the following:
a - you're using a bugzilla which pretends you're logged in as guest@bugzilla.tld
1. you visit bug 10 (public) and can add a comment as guest@bugzilla.tld
2. you try to visit bug 1 (private) and can't see it, you are already logged in, what should happen?

b - you're using a more normal bugzilla (e.g. bmo) and are logged in as you normally would be
1. you visit this bug 348208
2. you visit bug sheriffpass

currently you get:
You are not authorized to access bug 322423. (this bug number is subject to change, but isn't very likely to change.)

Technically there's no distinction between a/b. A is in some ways the pathological configuration. The way to make B interesting is to give yourself more than one account (I have 3, justdave has at least 2) with different permissions.

We don't have to fix that at the same time, but since you've provided a very good idea for how to improve the normal case, I'd wonder if you can help consider the edge case.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

12 years ago
Keywords: ue
(Reporter)

Comment 2

12 years ago
sorry for the delayed reply --- I need to see what happens to the bz mails I'm getting from this bz, I missed your comment :(

(In reply to comment #1)
> one question though. suppose any of the following:
> a - you're using a bugzilla which pretends you're logged in as
> guest@bugzilla.tld
> 1. you visit bug 10 (public) and can add a comment as guest@bugzilla.tld
> 2. you try to visit bug 1 (private) and can't see it, you are already logged
> in, what should happen?

If you can't see it you get a denial page.  The proposal is to allow entering login credentials on that very page, instead of a link to the login page.

In one sentence the proposal is to embed the login into any pages that deny access.

> b - you're using a more normal bugzilla (e.g. bmo) and are logged in as you
> normally would be
> 1. you visit this bug 348208
> 2. you visit bug sheriffpass
> 
> currently you get:
> You are not authorized to access bug 322423. (this bug number is subject to
> change, but isn't very likely to change.)
> 
> Technically there's no distinction between a/b. A is in some ways the
> pathological configuration. The way to make B interesting is to give yourself
> more than one account (I have 3, justdave has at least 2) with different
> permissions.


I'm confused.

how don't a and b  mix with having the login: and passowrd: fields embedded into any pages that deny access?

Updated

12 years ago
OS: Linux → All
Hardware: PC → All
You need to log in before you can comment on or make changes to this bug.