[
https://issues.apache.org/jira/browse/RAMPARTC-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560270#action_12560270
]
Malinda Kaushalye Kapuruge commented on RAMPARTC-56:
----------------------------------------------------
Right now the order of execution is as follows.
1. Check rampart context for a direct password
2. If not Check rampart context for a password callback function
3. If not Check rampart context for a password callback module
So there is no code change needed in the core functionalities. All we have to
provide is either the password directly to the message context or a callback
function to retrieve the password.
> 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: Glen Daniels
> 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.
