[JBossWS] - Re: Accessing USERNAME_PROPERTY from Web Service class
by mjhammel
I've spent all day on this and found nothing. It appears that *maybe* something called handlers or interceptors might be useful here. The password must be sent in the SOAP message but the question is how to pull it out. I think the PASSWORD_PROPERTY as set by the client is received on the server side (proven by the use of BASIC authentication using a database login module) but is not in the APPLICATION scope and therefore I can't get at it the way I've been trying. Which is what leads me to think the handlers or interceptors might have some way to get at it. But I'm still not clear on how to write handlers (and I'm not even sure what interceptors might be, other than they appear to be part of Apache CXF, whatever that is).
Maybe if I post enough messages in this thread someone at JBOSS will pay attention to it long enough to tell me "You can't get there from here." At least then I'd know I can stop wasting my time on it.
At this point it feels like I'm wasting my time on Web Services, which feel about as useful as Esperanto. *sigh*
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123277#4123277
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123277
17 years, 11 months
WS-Eventing: wsa:ReferenceParameters and multiple sources
by Dan Retzlaff
Hi,
I have two issues to discuss regarding the WS-Eventing extension to JBossWS.
1. Notifications don't reflect the wsa:ReferenceParameters provided
with subscriptions' NotifyTo and EndTo wsa:EndpointReferences. If my
understanding of WS-A is correct, each reference parameter should
appear as a top-level element in the SOAP header of notifications. Is
this not the case? I need it for a "SubscriptionID" field that allows
a recipient to identify the subscription which resulted in the
notification. The first patch, WSE-ReferenceParameters.patch,
introduces the desired behavior. I have to admit, I'm fuzzy on the
distinction between ReferenceParameters and ReferenceProperties. If
it's only the latter which is meant to have this behavior (as it is in
the examples in the WS-Eventing spec), then I can modify my
implementation and this patch.
2. Deploying a single event source, as in the sample provided, worked
fine. However, I ran into two problems with more than one event source
in the same deployment. Both problems are addressed in the second
patch, WSE-SourceInit.patch.
The first initialization bug was in
MetaDataBuilder::processEndpointMetaDataExtensions. This method is
called for each endpoint, and goes through the service's WSDL looking
for wsdl:portTypes with a wse:isEventSource attribute. For each such
portType, a EventingEpMetaExt extension is added to a map in
ServerEndpointMetadata indexed by the WS-E namespace. However, since
the namespace is the same for all such portTypes, only the last one
sticks around. Then during deployment, the EventingDeploymentAspect
registers each event source with the SubscriptionManager, but the
EventingEndpointDeployment has the wrong eventSourceNS for all but the
last portType processed by the MetaDataBuilder. The
SubscriptionManager depends on an eventSourceNS being registered
exactly twice: once for the source endpoint and once for the
subscription manager endpoint. But since the eventSourceNS for the
last portType gets registered twice, neither of which is the
subscription manager, the premature transition of the source to the
STARTED state causes its assertConfiguration() to fail. My solution is
to modify MetaDataBuilder::processEndpointMetaDataExtensions to not
add the EventingEpMetaExt for event sources that don't correspond to
the current endpoint's address. The SubscriptionManagerPort
(identified by the same dodgy string-literal comparison used in the
SubscriptionManager class) still gets all sources' EventingEpMetaExts.
The second initialization bug was that SubscriptionManager's
registerEventSource didn't ensure that all event sources went through
CREATED and STARTED states. In my case, this manifested itself with a
NullPointerException when an un-started EventSource tried to deliver a
notification. The patch refactors registerEventSource (and its
protected helper, updateManagerAddress). There's probably room for a
little polish here, but it works and I've spent too much time on this
already. :)
On a design note, I'm finding it cumbersome to have the event source
derive its URI from its WSDL portType QName. This, along with the
annotation approach to creating a non-abstract endpoint class,
requires a lot more configuration per event source than it feels like
should be necessary: a new portType, a new binding, a new service
port, a new servlet in web.xml, plus a new Java file that needs to be
compiled. Right now I'm autocoding all of these from a single source
XML (a custom annotated WSDL), but is this the best way? Does someone
have a suggestion for me?
Regards,
Dan
17 years, 11 months
[JBossWS] - Re: Accessing USERNAME/PASSWORD_PROPERTY from Web Service cl
by mjhammel
While finding the username wasn't as hard as first thought, it looks like finding the PASSWORD is. It doesn't seem to be in the HttpServletContext anywhere, nor can I find it in the MessageContext anywhere.
This piece of code:
/* Find out who the user is saying they are in the HTTP session. */
| MessageContext msgContext = wsContext.getMessageContext();
| HttpServletRequest servletRequest = (HttpServletRequest) msgContext.get(MessageContext.SERVLET_REQUEST);
| String username = servletRequest.getRemoteUser();
|
| Enumeration hdrs = servletRequest.getHeaderNames();
| for (; hdrs.hasMoreElements() ;)
| System.out.println("Header: " + hdrs.nextElement());
|
| String pathInfo = servletRequest.getPathInfo();
| String queryStr = servletRequest.getQueryString();
| String requestURI = servletRequest.getRequestURI();
| StringBuffer requestURL = servletRequest.getRequestURL();
| Principal p = servletRequest.getUserPrincipal();
| String sessionID = servletRequest.getRequestedSessionId();
|
| System.out.println("Path Info: " + pathInfo);
| System.out.println("Query String: " + queryStr);
| System.out.println("Request URI : " + requestURI);
| System.out.println("Request URL : " + requestURL.toString());
| System.out.println("Principal : " + p.toString());
| System.out.println("Session ID : " + sessionID);
|
| HttpSession session = servletRequest.getSession();
| Enumeration attrs = session.getAttributeNames();
| for (; attrs.hasMoreElements() ;)
| System.out.println("Session Attribute: " + attrs.nextElement());
produces the following output, which doesn't show any sign of the password property:
14:49:57,472 INFO [STDOUT] Header: authorization
| 14:49:57,472 INFO [STDOUT] Header: soapaction
| 14:49:57,472 INFO [STDOUT] Header: content-type
| 14:49:57,472 INFO [STDOUT] Header: jboss-remoting-version
| 14:49:57,472 INFO [STDOUT] Header: user-agent
| 14:49:57,472 INFO [STDOUT] Header: host
| 14:49:57,472 INFO [STDOUT] Header: accept
| 14:49:57,472 INFO [STDOUT] Header: connection
| 14:49:57,472 INFO [STDOUT] Header: content-length
| 14:49:57,475 INFO [STDOUT] Path Info: null
| 14:49:57,475 INFO [STDOUT] Query String: null
| 14:49:57,476 INFO [STDOUT] Request URI : /Crunch/comp/SubscriberServices
| 14:49:57,476 INFO [STDOUT] Request URL : https://localhost:8443/Crunch/comp/SubscriberServices
| 14:49:57,476 INFO [STDOUT] Principal : admin
| 14:49:57,476 INFO [STDOUT] Session ID : null
|
Note that there doesn't appear to be anything in the HttpSession either, which is probably correct though I'm not sure of that at the moment.
Does anyone know where the PASSWORD_PROPERTY set by the client is hiding when it gets to the Web Services class?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123219#4123219
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123219
17 years, 11 months
[JBossWS] - Re: Accessing USERNAME_PROPERTY from Web Service class
by mjhammel
Okay, I discovered how to do this. Part of the problem was that my BASIC authentication via DatabaseServerLoginModule was not working properly.
Ignoring the authentication problem, once you have authentication working then the following code should work:
| import javax.xml.ws.WebServiceContext;
| import javax.xml.ws.handler.MessageContext;
| import javax.servlet.http.HttpServletRequest;
| import java.security.Principal;
| ...
|
| @Stateless
| @Remote(SubscriberServices.class)
| @WebService(
| name = "SubscriberWS",
| endpointInterface = "com.cei.crunch.server.ws.SubscriberServices.SubscriberServicesEndpoint"
| )
| @SOAPBinding(style = SOAPBinding.Style.RPC)
|
| public class SubscriberServices implements SubscriberServicesEndpoint {
|
| @Resource
| WebServiceContext wsContext;
|
| private Subscriber getUserInfo() throws CrunchWSException {
|
| MessageContext msgContext = wsContext.getMessageContext();
| HttpServletRequest servletRequest = (HttpServletRequest) msgContext.get(MessageContext.SERVLET_REQUEST);
| Principal p = servletRequest.getUserPrincipal();
| String username = p.getName();
| ....
|
Alternatively:
| ...
| MessageContext msgContext = wsContext.getMessageContext();
| HttpServletRequest servletRequest = (HttpServletRequest) msgContext.get(MessageContext.SERVLET_REQUEST);
| String username = servletRequest.getRemoteUser();
| ...
Either method appears to work.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123148#4123148
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123148
17 years, 11 months