Accessing FS API without context (from WebApp)
Author: isac_jimenez
Publication Date: 4/30/2021 9:58
Hi experts!
I'm building a web application that needs to access the schedule tasks. I found the right classes in the documentation but I don't know how to do the requireSpecialist step without an actual context. Normally you would get the context from the method that gets called by FS, like for example ExecuteScript(ScriptContext) but in this case this WebApp will be called via URL so I don't know how to get that context...
Any ideas?
Thanks!
Tags: api
-
Author: felix_reinhold - 4/30/2021 10:46
ConnHi Isac,
I don't know, if this is the intended way to do this, but the last time we did this (about 6 years ago ;-) ) we added this to our web.xml of the global webapp:
<context-param>
<param-name>firstspirit.host</param-name>
<param-value>localhost</param-value>
</context-param>
<context-param>
<param-name>firstspirit.port</param-name>
<param-value>9001</param-value>
</context-param>
<filter>
<filter-name>WebAuthentication</filter-name>
<filter-class>de.espirit.firstspirit.io.servlet.WebAuthentication</filter-class>
<init-param>
<param-name>WebAppType</param-name>
<param-value>FS5ROOT</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>WebAuthentication</filter-name>
<url-pattern>/</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>WebAuthentication</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Then we received a connection via request.getSession().getAttribute("connection"); that we could use to get our SpecialistsBroker.
Best regards
Felix
0 -
Author: isac_jimenez - 4/30/2021 10:59
Thanks Felix for the quick turn around. This looks good, I'll try it and let you know if it worked.
Regards,
Isac Jiménez
0 -
Author: isac_jimenez - 5/5/2021 10:06
Hi Felix,
Thanks for the hint, it worked. I marked your response as the correct one.
However, any idea about how I can remotely authenticate? I tried basic authentication (I'm calling via Ajax) but that didn't work... Please let me know if I should open another discussion for this question.
Thanks,
Isac
0 -
Author: felix_reinhold - 5/5/2021 10:21
Hi Isac,
have you checked, if the filter-pattern applies for you?
In my case the WebAuthentiation-Filter redirects me directly to the FS ogin page.
Are you using tomcat or jetty? If I remember correctly the wildcard mapping is different for those two containers.
Regards
Felix
0 -
Author: isac_jimenez - 5/5/2021 12:00
Hi Felix,
Thanks again for the quick response. I'm using Tomcat and if I just go to the URL in the browser I indeed get redirected to the FS login page. However, this service is intended to be called from the outside so I would need to figure out a way of sending the authentication details along with the actual call. I tried with basic authentication from Javascript but that didn't seem to work, since I got the Unauthorized error.
Regards,
Isac Jiménez
0 -
Author: felix_reinhold - 5/5/2021 12:25
Hi Isac,
sorry, misunderstood the problem. In that case you don't even need to use the WebAuthentication Filter.
In your webapp just create your own connection via ConnectionManager.
e. g.:
Connection con = ConnectionManager.getConnection(host, port, mode, user, password);
ConnectionManager.setUseHttps(isHttps);
try {
con.connect();
} catch (Exception e) {
e.printStackTrace();
return false;
}
In that case you wouldn't even need to create the webapp as global webapp in FirstSpirit. It can placed on its own webcontainer as long as it able to access the FirstSpirit server but you'd need to provide the fs-access.jar in that case.
If the REST API doesn't require authentication of the user then just add the connection params to a config - otherwise create an endpoint for the auth.
Best regards
Felix
0 -
Author: isac_jimenez - 5/5/2021 13:58
Well, once again you solved my issue, thank you very much indeed. I've tried to get to the right documentation but I was not able to...
Now I'm facing an error when doing the connection:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
It's probably due to the certificate being self-signed... Do you know any way of forcing the connection to trust the certificate?
Thank you very much.
0 -
Author: felix_reinhold - 5/5/2021 14:32
Hi Isac,
2 ways imo:
- Create the connection via SOCKET (since it's running locally on the same server this shouldn't be a problem). Just set the param mode to ConnectionManager.SOCKET_MODE: ConnectionManager (FirstSpirit Access-API)
- Download the certificate and add it to the certificate store of your FirstSpirit server. By default the standard java certificate store is used located unter %JAVA_HOME%/lib/security/cacerts
Regards
Felix
0 -
Author: isac_jimenez - 5/6/2021 7:55
Hi Felix,
Thank you so much AGAIN for helping. I already feel bad for asking you so much but I can't find much documentation about it...
Importing the certificate did the trick but I'm having trouble doing the actual connection. I get an exception when doing con.connect(): "Connection closed" (see full trace at the end).
Not sure what I'm doing wrong, the code is pretty simple really:
Connection con = ConnectionManager.getConnection(<host_name>, 443, ConnectionManager.SOCKET_MODE, <user>, <pass>);
ConnectionManager.setUseHttps(true);
conn.connect().
I tried with setUseHttps(false) with same result.
I also tried with HTTP_MODE but then got the following error: module "access_api" is not licensed!
Don't know why I would need a license for http mode but not for socket mode... Do you think maybe this lack of license is what is making it fail in socket mode too?
Full trace:
Connection closed. de.espirit.firstspirit.client.io.ServerCaller$MessageResponseListener.getResponse(ServerCaller.java:1206)de.espirit.firstspirit.client.io.ServerCaller.call(ServerCaller.java:652)de.espirit.firstspirit.client.io.ServerCaller.call(ServerCaller.java:462)de.espirit.firstspirit.client.io.ServerCaller.callServer(ServerCaller.java:782)de.espirit.firstspirit.client.io.AbstractMessageCaller.ping(AbstractMessageCaller.java:67)de.espirit.firstspirit.client.io.SocketServerCaller.doConnect(SocketServerCaller.java:47)de.espirit.firstspirit.client.io.ServerCaller.connect(ServerCaller.java:189)de.espirit.firstspirit.client.io.ConnectionImpl.connect(ConnectionImpl.java:185)de.ivv.map.fs.portalserviceconsumer.deploymentstatus.CallPortalService.doGet(CallPortalService.java:29)javax.servlet.http.HttpServlet.service(HttpServlet.java:622)javax.servlet.http.HttpServlet.service(HttpServlet.java:729)org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:614)org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:528)org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1099)org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:670)org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)java.lang.Thread.run(Unknown Source)
Regards,
Isac Jimenez
0 -
Author: felix_reinhold - 5/6/2021 10:14
Hi Isac,
oh, wouldn't have thougt that you don't have ACCESS_API licensed. Haven't seen a project for ages where this is not licensed cause it's a pain working without it.
I'd guess that the fail in SOCKET_MODE is because of the same reason. If you're developiing FirstSpirit Modules in this project you should definitely think about licensing it. Otherwise you'd have to use the baseAuth. I used it in another project many years ago - I'll check if I can find the sources of that. You can also check the different login modules for information about basic auth:Documentation for Administrators - Login process configuration (fs-jaas.conf)
0 -
Author: isac_jimenez - 5/6/2021 11:11
Hi Felix,
Thank you very much again. I really appreciate it. I'll discuss licensing with the client and explore other alternatives, like you suggested.
Kind regards,
Isac Jiménez
0 -
Author: felix_reinhold - 5/6/2021 12:59
isac.jimenez Yes - I guess that would be the best idea. If you want to test the implementation first before licensing it: Don't you have a local developing environment with FirstSpirit running? I think the ACCESS-API is activated by default in the developer linceses provided to partners. Don't know if there's a difference cause BOLDLY GO is just a Standard Partner. Maybe you could talk with your partner manager about this topic.
0 -
Author: isac_jimenez - 5/6/2021 14:26
Thanks Felix, I don't think we have such environment but I'll double check.
By the way, I took the liberty to send you an email to the account you have in your website (found it in your profile), just to say thanks.
0
Please sign in to leave a comment.
Comments
13 comments