Bug 471681 - DSGW authenticate multi-result hyperlinks broken
Summary: DSGW authenticate multi-result hyperlinks broken
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: UI - Gateway/Phonebook
Version: 1.1.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: FDS1.1.4 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2008-11-14 23:07 UTC by jsullivan
Modified: 2015-12-07 16:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:38:02 UTC


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

Description jsullivan 2008-11-14 23:07:07 UTC
Description of problem:
Hyperlinks returned when multiple users meet the search criteria for authentication do nothing

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

How reproducible:
Always

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:
nothing

Expected results:
Option to enter password for the selected user

Additional info:

Comment 1 Rich Megginson 2008-12-22 19:02:32 UTC
Created attachment 327681 [details]
diffs

Comment 2 Rich Megginson 2008-12-22 19:51:34 UTC
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 06:15:47 UTC
Based on comment#4, marking as VerifiedUpstream


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