[
https://wso2.org/jira/browse/MASHUP-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18042#action_18042
]
Jonathan Marsh commented on MASHUP-793:
---------------------------------------
The issues are now:
1) document the parameters
2) consider simplified API with un/pw only available as parameters instead of
options (two ways are more complicated than one). Maybe this is moot since we
are acruing legacy. Maybe time to drop this idea.
Glad to see the stub is working with UT in the host object. It wasn't when I
first filed the bug.
> 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://wso2.org/cgi-bin/mailman/listinfo/mashup-dev
