[JIRA] Updated: (EDS-24) The embedded discovery service will fail to work with Internet Explorer when native XHR is disabled

[Rod Widdowson (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/EDS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rod Widdowson updated EDS-24:
-----------------------------

    Fix Version/s:     (was: 1.1)
                   1.0.2

> The embedded discovery service will fail to work with Internet Explorer when native XHR is disabled
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EDS-24
>                 URL: https://issues.shibboleth.net/jira/browse/EDS-24
>             Project: Embedded Discovery Service
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Internet Explorer >= 7, with native XMLHttpRequest disabled by policy, etc.
>            Reporter: nsroy at uiowa.edu
>            Assignee: Rod Widdowson
>            Priority: Minor
>             Fix For: 1.0.2
>
>         Attachments: idpselect.js
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Believe it or not, there are some places that deploy Internet Explorer, and force users to use it.  Even a modern version like IE8, but then they set a group policy that disables (for some odd reason) native XMLHttpRequest support (see: http://msdn.microsoft.com/en-us/library/ms537505(v=vs.85).aspx) These places frequently leave ActiveX enabled (no comment).  This leaves an avenue open for using the old ActiveX-based XHR object.  The embedded DS does not try to fall back to this method, even if available.  It would be nice to see this support.  I have some proof of concept code of this working:
> var xmlHttp; 
> if (window.XMLHttpRequest)
> {
> 	xmlHttp = new XMLHttpRequest(); 
> }
> else if (window.ActiveXObject)
> {
> 	xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
> }
> else
> {
> 	xmlHttp = null;
> }
> Then in the EDS, I simply replaced:
> try{aA=new XMLHttpRequest()}
> with:
> try{aA=xmlHttp}
> This fixed the issue for these oddly configured clients.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira