Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

Did HTTP receiver changed from V2.8.6 ?

  • Good day,

    I'm checking the new V3 and i can't receive HTTP POST from an other device with http receiver.

    The exact same setting is working with core 2.8.6.

    basically i'm trying to send http post from Node-Red.
    with the following code;

    msg.payload = "testpara=22";
    msg.headers = {'content-type':'application/x-www-form-urlencoded'};
    return msg;

    trough the http request node in POST on the mango server address.

    I receive it in Mango 2.8.6 but not in 3.0.1. with the receivers set up in the exact same settings.
    In 2.8.6 :0_1493370809118_Screen Shot 2017-04-28 at 11.10.59.png

    In 3.0.1 it doesn't receive anything.

    Any clue ?

  • I have this message in the console :

    WARN  2017-04-28T14:54:02,077 ( - Denying access to Mango resource Could not verify the provided CSRF token because your session was not found.
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at org.springframework.web.filter.OncePerRequestFilter.doFilter( [spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    	at$VirtualFilterChain.doFilter( [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at org.springframework.web.filter.OncePerRequestFilter.doFilter( [spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    	at$VirtualFilterChain.doFilter( [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at$VirtualFilterChain.doFilter( [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at org.springframework.web.filter.OncePerRequestFilter.doFilter( [spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    	at$VirtualFilterChain.doFilter( [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at [spring-security-web-4.1.1.RELEASE.jar:4.1.1.RELEASE]
    	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate( [spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    	at org.springframework.web.filter.DelegatingFilterProxy.doFilter( [spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter( [jetty-servlet-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.servlet.ServletHandler.doHandle( [jetty-servlet-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.ScopedHandler.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at [jetty-security-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.session.SessionHandler.doHandle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.ContextHandler.doHandle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.servlet.ServletHandler.doScope( [jetty-servlet-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.session.SessionHandler.doScope( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.ContextHandler.doScope( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.ScopedHandler.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.handler.HandlerWrapper.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.Server.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.HttpChannel.handle( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.server.HttpConnection.onFillable( [jetty-server-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at$ReadCallback.succeeded( [jetty-io-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at [jetty-io-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at$ [jetty-io-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume( [jetty-util-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume( [jetty-util-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at [jetty-util-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( [jetty-util-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at org.eclipse.jetty.util.thread.QueuedThreadPool$ [jetty-util-9.3.11.v20160721.jar:9.3.11.v20160721]
    	at [?:1.8.0_121]

  • Hi philgdep,

    Can you share how you're trying to publish data to it? I just confirmed it's working fine, and the CSRF message is not related (it's not happening every time you attempt to publish, is it? If so, I wonder if you're publishing to http://ip:port/httpds). Are you using the alias 'localhost' for your server? If so, it's possible IPv6 is being resolved. The whitelists don't currently support IPv6, so if the incoming IP is ::1 it will get denied.

    Here's some text I was able to get a value from using nc 80 < httpPub.txt

    GET /httpds?brown=8.905449871164275%4020170428091914 HTTP/1.1
    User-Agent: Mango M2M2 HTTP Sender publisher
    Host: localhost:8088
    Connection: Keep-Alive
    Accept-Encoding: gzip,deflate

    Gotten by a nc -l 8088 and pointing the publisher at that port/httpds so some of the details (like the host header or user agent) aren't exactly correct (User-agent netcat!), but it works.

  • Nevermind. I have attempted the same exercise with Post and encountered this issue. It's related to some security enhancements. I will work to get this resolved as quickly as possible.

  • Hi Philgdep,

    I have emailed you a fix if you need it right this moment. We will be updating this in the store download soon.

  • @phildunlap Thanks a lot ! its working now. You guys are very efficient!

    The fix you sent me will be ok or the later store version will be better ? Just to know if I have to delete de override file later?


  • Thanks! We try!

    It's always better not to use overridden classes, but we like to enable people to resume whatever they were doing when they discovered an issue as quickly as possible, but it does make a moment more of work during an upgrade. You'll definitely need to delete the overrides when updating.

  • @phildunlap What is the fix here? I am trying with 3.4.4 using HTTP JSON receiver listener and I am seeing the same error.

  • I believe the fix was creating an exclusion such that no XSRF was required on the http://host:port/httpds URL Shouldn't really be possible still. Do you have any details about how it's being caused?

    For instance, i was able to post this message from a publisher to a receiver, and receive the value in an alphanumeric point with the HTTP parameter name on thE JSON receiver set to /p1

    POST /httpds HTTP/1.1
    User-Agent: Mango M2M2 HTTP Sender publisher
    Content-Type: application/json
    Content-Length: 49
    Connection: Keep-Alive
    Expect: 100-continue
    Accept-Encoding: gzip,deflate
      "p1" : "52.81569485688922@20180625082854"

    My receiver was on 3.4.4

  • Got it thanks.