[
https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561936#action_12561936
]
Malinda Kaushalye Kapuruge commented on RAMPARTC-56:
----------------------------------------------------
Here is my suggestion...
We may use a new structure called rampart_config_t and set it to the
axis2_svc_client_t
Inside the rampart_config_t we can have following members.
1. username
2. password
Later we can evolve this new struct to hold certificates. password callback
functions, TTL values and all the other configurations. In this way we do not
need to change the axis2_svc_client_t for each and every new security
requirements.
> Avoid deploying password callback modules in the client code
> ------------------------------------------------------------
>
> Key: RAMPARTC-56
> URL: https://issues.apache.org/jira/browse/RAMPARTC-56
> Project: Rampart/C
> Issue Type: Improvement
> Components: Rampart-core
> Affects Versions: 1.2.0
> Environment: N/A
> Reporter: Malinda Kaushalye Kapuruge
> Assignee: S.Uthaiyashankar
> Fix For: 1.2.0
>
>
> Right now in order to get the password, the client has to write a password
> callback module and deploy it. And then refer the name of the dll via the
> policy descriptor. This is quite unnecessary, if we can provide a callback
> function in the client code.
> So my suggestion is that we set a pointer of the callback function in to the
> message context within the client code. Later when the rampart context is
> created, we can transfer this function pointer to the rampart context.
> In this way without changing the core functionalities we can get rid of the
> password callback modules in the client side.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
