Bug 471681 - DSGW authenticate multi-result hyperlinks broken
DSGW authenticate multi-result hyperlinks broken
Product: 389
Classification: Community
Component: UI - Gateway/Phonebook (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
: VerifiedUpstream
Depends On:
Blocks: FDS1.1.4 FDS1.2.0
  Show dependency treegraph
Reported: 2008-11-14 18:07 EST by jsullivan
Modified: 2015-12-07 11:38 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-07 11:38:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diffs (3.12 KB, patch)
2008-12-22 14:02 EST, Rich Megginson
no flags Details | Diff
cvs commit log (457 bytes, text/plain)
2008-12-22 14:51 EST, Rich Megginson
no flags Details

  None (edit)
Description jsullivan 2008-11-14 18:07:07 EST
Description of problem:
Hyperlinks returned when multiple users meet the search criteria for authentication do nothing

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Create users with similar IDs in DS, e.g., tjohnson and cjackson
2.Enter DSGW and choose Directory Server Gateway
3.Choose authenticate
4.enter "son" in the search box
5.click continue
6.click on one of the returned hyperlinks - nothing happens
Actual results:

Expected results:
Option to enter password for the selected user

Additional info:
Comment 1 Rich Megginson 2008-12-22 14:02:32 EST
Created attachment 327681 [details]
Comment 2 Rich Megginson 2008-12-22 14:51:34 EST
Created attachment 327685 [details]
cvs commit log

Reviewed by: nhosoi (Thanks!)
Fix Description: 1) The quoting was a bit off.  The DSGW code adds double quotes at the beginning and end of the javascript.  We have to use %22 to have DSGW emit double quotes in the right places where other double quotes are needed.
2) If you are attempting to auth as a real user, and you have password policy on such that the user must change the password after reset, and you are using a binddn instead of the default anon, the auth screen would not prompt you for your old password, because it thought you were already bound as the binddn.  The binddn is not a real user in this case, and so should not be considered when testing for "bound".
Platforms tested: RHEL5
Flag Day: no
Doc impact: no
Comment 5 Amita Sharma 2011-07-20 02:15:47 EDT
Based on comment#4, marking as VerifiedUpstream

Note You need to log in before you can comment on or make changes to this bug.