Forum Discussion
7 Replies
Sort By
- SmartBear_SuppoSmartBear Alumni (Retired)Hi,
hmm.. can you attach the WSDL's generated by WebLogic for your service with and without this option set?
regards,
/Ole
eviware.com - MariateresaNew ContributorThere is no difference in the two WSDLs.
When the roles annotation is defined at method level I get the following error, but when the annotation is at class level the call works fine:
soapenv:Client.Authentication
Access Denied to operation executePARPRequest
weblogic.wsee.util.AccessException: Access Denied to operation executePARPRequest
at weblogic.wsee.security.AuthorizationHandler.handleRequest(AuthorizationHandler.java:62)
at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:127)
at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
...
Thanks, Mariateresa - JimLContributorHi,
When you say that there is no difference between the two WSDLs, where are you looking at/getting the WSDLs from?
With WebLogic, if you have a webservice, with policy, etc. annotations, and you go to the WSDL URL (http://yourhost/your_webservice_uri?WSDL, you'll get a 'dynamic' WSDL, which incorporates things like policy files, etc. that get pulled in by things like the "@policy" annotation.
A WSDL that you get generated using, for example, by using Workshop won't have that policy stuff in the WSDL.
So, to answer Ole's question, you'd need to build your webservice with the @RolesAllowed at the class level, deploy it, then point your browser to the ?WSDL URL, to get 1 WSDL.
Then, you'd need to modify your webservice code to put the @RolesAllowed at the operation/method level, rebuild the EAR, re-deploy it, then point your browser to the ?WSDL URL again, to get the 2nd WSDL.
Those are the two WSDLs that he's looking for, I think.
BTW, when you try to use SOAPUI, I think (not sure) that you'd need to import the appropriate WSDL.
Jim - MariateresaNew ContributorThanks for the clarification.
There is no difference in the two WSDLs created dynamically.
However, one difference is that when I request the WSDL from the browser, for the version of the webservice with roles at method level, I don't get prompted for username/password, while I get prompted for username/password when I request from the browser the WSDL for the webservice with roles at class level.
Thanks, Mariateresa - SmartBear_SuppoSmartBear Alumni (Retired)Hi,
ok.. then maybe you just need to add username/password credentials in the AUT tab under the request and also enable preemptive authentication in the global HTTP Preferences!?
regards!
/Ole
eviware.com - JimLContributor
Mariateresa wrote:
Thanks for the clarification.
There is no difference in the two WSDLs created dynamically.
However, one difference is that when I request the WSDL from the browser, for the version of the webservice with roles at method level, I don't get prompted for username/password, while I get prompted for username/password when I request from the browser the WSDL for the webservice with roles at class level.
Thanks, Mariateresa
Hi,
I'm assuming that when you said that you "get prompted for username/password", you mean that you get a popup login window? If that's the case, and while I don't really understand why you'd get the popup in one case versus the other, you might try what is suggested here:
http://reference.mapinfo.com/software/e ... -2-07.html
i.e., add:false
to your config.xml.
You'll need to bounce the WebLogic domain/admin server after making that change.
I had that (popup) happen when I was doing some testing with trying to get message-level username/password token working with WebLogic.
Like I said, it doesn't make sense to me that you'd get it with the @RolesAllowed at one place vs. the other, but give it a try.
Hope that this helps.
Jim - MariateresaNew ContributorI'll try what you suggest and let you know...
Thanks! Mariateresa
Related Content
- 5 years agopaulvinders
- 11 months agoSiKing
- 31 days agoNicolaFilosa_SE
Recent Discussions
- 15 hours agoruchisingh