Bug 471681

Summary: DSGW authenticate multi-result hyperlinks broken
Product: [Retired] 389 Reporter: jsullivan
Component: UI - Gateway/PhonebookAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: low Docs Contact:
Priority: medium    
Version: 1.1.1CC: amsharma, nhosoi
Target Milestone: ---Keywords: VerifiedUpstream
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:38:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 467277, 493682    
Attachments:
Description Flags
diffs
none
cvs commit log none

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