I'm trying the Camunda Enterprise today and notice the issue:
java.lang.IllegalStateException: Cannot create a session after the response has been committed
at org.apache.catalina.connector.Request.doGetSession(Request.java:2993)
at org.apache.catalina.connector.Request.getSession(Request.java:2432)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:908)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at org.camunda.bpm.webapp.impl.security.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at com.parkway.camunda.config.filter.CorsFilter.doFilterInternal(CorsFilter.java:25)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
...
Not sure this one is a bug or not ?
Only happen on
Spring-Boot: (v2.2.1.RELEASE)
Camunda BPM: (v7.12.0-ee)
Camunda BPM Spring Boot Starter: (v3.4.0)
I've tried with the same set of code and it's working fine on
Spring-Boot: (v2.2.1.RELEASE)
Camunda BPM: (v7.10.0)
Camunda BPM Spring Boot Starter: (v3.2.0)
Can someone help me to check ?
Thanks,
After search on the Internet for a day, I finally found the issue.
Root cause: because I'm calling REST API outside of Camunda website without turn on the Authentication mechanism and also using /api/abc/do-something
Ref: https://docs.camunda.org/manual/7.6/reference/rest/overview/authentication/
The REST API ships with an implementation of HTTP Basic Authentication. By default it is switched off.
Any request that does not address a specific engine (i.e., it is not of the form /engine/{name}/...) will be authenticated against the default engine.
Solution:
Change API path: from /api/abc/do-something -> /engine/api/abc/do-something
Switch on the Authentication by adding this configuration class (if you are using Spring Boot)
#Configuration
public class CamundaSecurityFilter {
#Bean
public FilterRegistrationBean processEngineAuthenticationFilter() {
FilterRegistrationBean registration = new FilterRegistrationBean();
registration.setName("camunda-auth");
registration.setFilter(getProcessEngineAuthenticationFilter());
registration.addInitParameter("authentication-provider",
"org.camunda.bpm.engine.rest.security.auth.impl.HttpBasicAuthenticationProvider");
registration.addUrlPatterns("/*");
return registration;
}
#Bean
public Filter getProcessEngineAuthenticationFilter() {
return new ProcessEngineAuthenticationFilter();
}
}
Thanks to this guys: https://forum.camunda.org/t/turn-on-basic-http-authentication-for-rest-api-in-spring-boot/3431
Related
I am using Spring Boot 2 Microservices with Spring Cloud Sleuth with the Dependency Management and Spring Cloud Version Greenwich.SR2.
My service is running in an Istio service mesh.
Sample policy of istio is set to 100 (pilot.traceSampling: 100.0).
To use distributed tracing in the mesh, the applications needs to forward HTTP headers like the X-B3-TraceId and X-B3-SpanID. This is achieved by simply adding Sleuth. All my HTTP request are are traced correctly. The sidecar proxies of Istio (Envoy) send the traces to the Jaeger backend.
Sleuth is also supposed to work with Spring WebSocket. But my incoming websocket requests do not get any trace or span id by sleuth; Logs look like [-,,,].
1. Question: Why is Sleuth not working for websocket?
My WS-Config:
#Configuration
#EnableWebSocket
public class WsConfig implements WebSocketConfigurer {
#Autowired
WebSocketHandler webSocketHandler;
#Override
public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
DefaultHandshakeHandler handshakeHandler = new DefaultHandshakeHandler();
handshakeHandler.setSupportedProtocols(HANDSHAKE_PROTOCOL);
registry.addHandler(webSocketHandler, WS_HANDLER_PATH + WILDCARD)
.setAllowedOrigins("*")
.setHandshakeHandler(handshakeHandler);
}
}
My clients are able to connect to my Service via Websocket. I am implementing WebSocketHandler interface to handle WS messages.
To achieve that my WS connections are logged by Sleuth, I annotate the method that handles my connection with #NewSpan:
#Override
#NewSpan
public void handleMessage(WebSocketSession session, WebSocketMessage<?> message) {
//doWork and call other services via HTTP
}
With this, Sleuth creates trace and spanId and also propagates them to the other Services, which are called via the restTemplate in this method. But HTTP calls are not send to Jaeger. The x-B3-Sampled Header is always set to 0 by the sidcar.
2 Question: Why are those traces not send to the tracing backend?
Thank you in advance!
I have a lot of proxies in WSO2 ESB that I have to securize. I need them to be securized using Username Token when deploy, instead of browsing to the dashboard and enabling it one by one.
Any help?
I guess currently, you need to use management console and do it. From the UI, it is calling a backend web service. You can automate process by automating this backend web service. This web service is exposed by following component [1]. You can use soapui or some client program to automate this web service.
[1] http://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/security/org.wso2.carbon.security.mgt/
I had similar requirement, here is how I solved it
Apply Role security to WSO2 ESB Proxy using Java API
Also you can find the test case here on how to use the methods
http://svn.wso2.org/repos/wso2/tags/carbon/3.2.3/products/bps/2.1.1/modules/integration/org.wso2.bps.management.test/src/test/java/org/wso2/bps/management/SecurityTest.java
Well here how the code snippet goes to secure any proxy service with default security scenarios of WSO2 ESB. In WSO2 ESB "scenario1" signifies Usernametoken based security. Now if you wish to secure your proxy with scenario1 follow the below code snippet:
public void applySecurityOnService(String serviceName, String policyId,
String[] userGroups, String[] trustedKeyStoreArray,
String privateStore)
throws SecurityAdminServiceSecurityConfigExceptionException,
RemoteException {
ApplySecurity applySecurity;
applySecurity = new ApplySecurity();
applySecurity.setServiceName(serviceName);
applySecurity.setPolicyId("scenario" + policyId); //scenario1 i.e. for Usernametoken security policyId should be 1
applySecurity.setTrustedStores(trustedKeyStoreArray);
applySecurity.setPrivateStore(privateStore);
applySecurity.setUserGroupNames(userGroups);
stub.applySecurity(applySecurity);
_logger.info("Security Applied Successfully");
}
Here is how you may call this method from your client class:
applySecurityOnService("MyProxy", "1", new String[]{"TestRole"}, new String[]{"wso2carbon.jks"}, "wso2carbon.jks");
I tried to deploy in GlassFish JAX-WS web service,
Here is a snippet of class were the web service is defined. Pay attention that I implemented Provider interface on EJB endpoint.
#Stateless(name = "HelloWorldEJBWS")
#WebServiceProvider(
portName = "HelloWorldWSPort",
serviceName = "HelloWorldWSService",
targetNamespace = "http://ivan.com/",
wsdlLocation ="HelloWorldEJBProvider.wsdl")
#ServiceMode(value = Service.Mode.PAYLOAD)
public class HelloWorldEJBWS implements Provider<Source> {
public Source invoke(final Source inRequestMessage) {
...
}
}
The problem is about the deploying the service in GlassFish (3.1.2.2) . F.
[#|2012-09-08T16:39:15.682-0400|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=20;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB HelloWorldEJBWS: [java:global/JAX-WS_GreetingEJBMutualAuthProvider/HelloWorldEJBWS, java:global/JAX-WS_GreetingEJBMutualAuthProvider/HelloWorldEJBWS!javax.xml.ws.Provider]|#]
[#|2012-09-08T16:39:15.792-0400|INFO|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=20;_ThreadName=Thread-2;|WS00019: EJB Endpoint deployed
JAX-WS_GreetingEJBMutualAuthProvider listening at address at http://ABRAMOV1:8088/HelloWorldWSService/com.ivan.wsejb.provider.HelloWorldEJBWS|#]
Even it shows the endpoint is deployed - is not . I can't reach this endpoint and it is not shown in GlassFish console.
For comparison I provide the log when I deployed the service using #WebService but not #WebServiceProvider
[#|2012-09-08T16:41:50.514-0400|INFO|glassfish3.1.2|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=22;_ThreadName=Thread-2;|WS00019: EJB Endpoint deployed
JAX-WS_GreetingEJBMutualAuth listening at address at http://ABRAMOV1:8088/HelloWorldEJBWSService/HelloWorldEJBWS|#]
In this case endpoint deployed correctly and everything is working fine.
Here is snipped of the code when I apply #WebService
#Stateless(name = "HelloWorldEJBWS")
#WebService()
public class HelloWorldEJBWS {
public String hello(final String inMessage) {
...
}
}
Did I do something wrong ?
I did everything right but was mislead by GlassFish. It could be a a bug...
When I deploy web service with endpoint implemented as servlet (second case) in the console I can see endpoint, but in case with endpoint implemented as EJB the endpoint did not appear in the console. But I could access the WSDL with a link http://localhost:8088/HelloWorldWSService/com.ivan.wsejb.provider.HelloWorldEJBWS?wsdl and ultimately tested web service with the client
I have two servlets that access two corresponding Axis2 web services on the same host. One of the servlets is read-only, while the other writes to a database.
Each of the Axis2 web services uses BASIC authentication. The read-only web service uses a system account, while the write web service uses the user's credentials (which are submitted as part of a web form).
The problem I'm running into is that the servlet called second always fails authentication to its web service. For example, I can query the read-only service through it's servlet all I want, but I get a "401: Authorization Required" when I try to use the write service. If I call the write service first, I get the same error when I try to use the read-only service.
Here is how I am setting the credentials for the connections in the servlets:
Stub service = new Stub(serviceUrl);
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
auth.setUsername(username);
auth.setPassword(password);
auth.setPreemptiveAuthentication(true);
service._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, auth);
The servlet that accesses the read-only service has this code in it's constructor. The servlet that accesses the write service has this code in it's doGet/doPost method.
It seems that the credentials for the first service called are getting cached somewhere, but I can't find where that could be. I saw a possible solution here, but I can't find where WSClientConstants.CACHED_HTTP_STATE is defined. The comments in this JIRA issue seems to imply that it's part of org.apache.axis2.transport.http.HTTPConstants but it's not there.
Specifics:
Axis version: 1.5.1
Tomcat Version: 6.0.26
Java version: 1.6.0_23
It turns out the connections to the two different services were using the same JSESSIONID. Thus, the connection to the second web service was trying to use a session authenticated for the first web service, causing the error.
My solution for this was to define an HttpClient for each service, done by the following
MultiThreadedHttpConnectionManager manager = new MuliThreadedHttpConnectionManager();
HttpClient client = new HttpClient(manager);
ConfigurationContext context = ConfigurationContextFactory.createDefaultConfigurationContext();
context.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, client);
context.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true);
Stub service = new Stub(context, serviceUrl);
This allows both servlets to have a separate session for their corresponding services.
The important point is to create a dedicated ConfigurationContext.
I've solved in a simpler way using a default config context when creating the stub without the multithreaded connection factory
stub = new MyStub(ConfigurationContextFactory.createDefaultConfigurationContext(), myServicesUrl);
i have a local client j2se application and backend is derby(javadb) database and dao is jpa eclipselink .
how do i send these database pojo to a remote database which linked with spring ( jsp) application on tomcat server
simply this is a rich client with swing which connects to tomcat deployed web application. The client should receive data and send data through HTTP requests to the server-side of the service,
what would be the best solution ??
01) direct database connection/transaction through socket using Eclipselink
02) web service ??
03) just send post request to spring web application and convert it to POJO and persist to database
how do i achieve this??
DISCLAIMER I am not suggesting you port your app from Spring to EJB. Despite how people like to compare them as exclusively one or the other, you can use them both. Its your app, you can be as pragmatic as you want to be :)
You don't necessarily have to use Web Services if you wanted. You could drop the OpenEJB war file into Tomcat as well and create an Remote EJB to send data back and forth.
Once you drop in OpenEJB you can put a remote #Stateless bean in your app like so:
#Stateless
#Remote
public class MyBean implements MyBeanRemote {
//...
}
public interface MyBeanRemote {
// any methods you want remotely invoked
}
Then look it up and execute it over HTTP from your Swing app like so:
Properties p = new Properties();
p.put("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
p.put("java.naming.provider.url", "http://tomcatserver:8080/openejb/ejb");
// user and pass optional
p.put("java.naming.security.principal", "myuser");
p.put("java.naming.security.credentials", "mypass");
InitialContext ctx = new InitialContext(p);
MyBean myBean = (MyBean) ctx.lookup("MyBeanRemote");
Client-side all you need are the openejb-client.jar and javaee-api.jar from the OpenEJB war file and your own classes.
Since it's already a Spring app don't bother trying to use #PersistenceContext to get a reference to the EntityManager so the EJB can use it. Just figure out how to expose the EntityManagerFactory that Spring creates (or you create) to the EJB via any means possible. The direct and ugly, but effective, approach would be a static on the MyBean class and a bit of startup logic that sets it. You'd just be using the EJB for remoting so no need for fancier integration.
If you did really need web services for non-java communication or something, you can add #WebService to the top of your bean and then it will have WSDL and all that generated for it:
#Stateless
#Remote
#WebService(portName = "MyBeanPort",
serviceName = "MyBeanService",
targetNamespace = "http://superbiz.org/wsdl"
endpointInterface = "org.superbiz.MyBeanRemote")
public class MyBean implements MyBeanRemote {
//...
}
public interface MyBeanRemote {
// any methods you want remotely invoked
}
Then you can also use the same bean as a web service like:
Service service = Service.create(
new URL("http://tomcatserver:8080/MyBeanImpl?wsdl"),
new QName("http://superbiz.org/wsdl", "MyBeanService"));
assertNotNull(service);
MyBeanRemote myBean = service.getPort(MyBeanRemote.class);
Both approaches are over http, but the web service approach will be a bit slower as it isn't a binary protocol.