[
https://wso2.org/jira/browse/MASHUP-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588#action_16588
]
Keith Godwin Chapman commented on MASHUP-793:
---------------------------------------------
supplying un/pw via both open method and options are possible. The options
overide the credentials given in open method. And both mechanisms work for HTTP
basic auth and ws-sec depending on the useWSS option.
> WSRequest host object doesn't accept optional username/password properties
> --------------------------------------------------------------------------
>
> Key: MASHUP-793
> URL: https://wso2.org/jira/browse/MASHUP-793
> Project: WSO2 Mashup Server
> Issue Type: Bug
> Reporter: Jonathan Marsh
> Assignee: Keith Godwin Chapman
> Fix For: 1.1
>
>
> The documentation and native version both take optional username and password
> properties
> on the WSRequest.open method, yet the WSRequest host object doesn't seem to.
> Instead
> it uses username and password options.
> I think this needs to be rationalized (and the host object or the native
> version fixed.)
> 1) The original design point for WSRequest was to duplicate the XMLHTTP
> object, which has
> optional un/pw parameters. While it's not clear this design point was a
> brilliant idea, we
> should either stick with it or do a total redesign.
> 2) Username/password are different from any other options data. Credentials
> are runtime
> information, rather than configuration information. This is illustrated
> by the fact that all
> the other options can be inferred from the WSDL, but the
> username/password can't, and
> must be collected at runtime.
> 3) WSRequest.js currently uses a hybrid approach which isn't very nice. It
> passes username/
> password into WSRequest.js, which then stores them temporarily as
> properties on the
> WSRequest object. Then it constructs the "options" for the endpoint
> based on information
> saved from the WSDL. Then it adds the username/password values to these
> options
> so that the WSS headers can be constructed from them. Yuk! It would be
> much
> cleaner to pass username/password down at each stage, or have an object
> similar to
> options to encapsulate them (and anything else we might need at runtime)
> My preference is to keep the "useWSS" option, but to drop the "username" and
> "password"
> options in favor of using the optional parameters on WSRequest.open(). I'm
> going to go ahead
> and implement this in WSRequest.js but it won't be too hard to back that out
> if we decide
> the options are a better approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Mashup-dev mailing list
[email protected]
http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
