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 support@radixiot.com.
Configuration of HTTP headers
-
Gary,
You can edit the JSP tags that build the page. They are located at:
web/WEB-INF/tags/page.tag
Or potentially the header tag here:
web/WEB-INF/tags/page/header.tag
I believe this will work for what you want to do. Let me know if you have any issues.
-
Thanks Terry but these are the wrong files for what I'm after. They contain partial HTML content for something. I'm not looking to modify content and the system I'm hoping to affect only outputs JSON. I need to modify HTTP headers, specifically for the Mango API, but I would not be surprised if this is a setting somewhere that also affects JSP scripts and even the Mango web interface (configuration of headers for the web interface doesn't seem like a great idea but is not something that greatly concerns me).
-
Gary,
Ok, I understand now. I didn't realize this was for the API JSON output. I can definitely add this to the pre-release module I am building for you.
Here is a link to how I will implement it, the section on Filter requests for CORS about half way down the page is what I will be doing and is all you need to read to get an idea of how it will work.
https://spring.io/guides/gs/rest-service-cors/
These are the 4 headers that I am planning on allowing, is this sufficient or would you prefer a free-text type of system where all you need to do is supply name/value pairs that will be added as headers to all response? Either way you will be allowed to change the values for the headers, they will not be hard coded as in the above example.
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Max-Age
Access-Control-Allow-HeadersTerry
-
Gary,
Here is a pre-release of the API Module. I've added the XID to the realtime web socket payload and also added the optional CORS headers.
To use the CORS headers take a look at the mangoApi/classes/mangoApiHeaders.properties file. Anything in the file not prefixed with # will be added as a name/value pair header for any mangoHost/rest/* URL
To enable the filter you will need to modify the web.xml file in the /web folder of the core. Check the mangoApiHeaders.properties file for the text to input. Just place that code (without the #'s prepending the lines) into that file near the <filter> section.
I realize this isn't ideal but for now it will have to work. Just remember that on every update of Mango's core you will need to replace these lines into the web.xml file. Hopefully by the next release this will be part of the core and not an issue for you.
Attachment: download link
-
Gary,
I just realized that the user REST endpoint will not work with your core version. Hopefully you are not doing anything with this endpoint and the module works for what you need. If you experience any problems let me know and I'll figure something out. We have re-designed the User permissions for the next release of Mango and our development stream is out of alignment with our current release stream.
Thanks,
Terry -
Thanks Terry.
The four headers seem sufficient but I think free text control would be a more appropriate long term solution. I would like free text control of headers to be a low priority entry on your to-do list.
I tried to test what you have done but unfortunately I encountered the problem you said I would with the REST API. As log on is a prerequisite to other endpoints, I am having to revert to the the previous version.
Gary
-
Gary,
I had a few minutes to roll back my code to a point where I could merge these new features into a module compatible with 2.5.2. I've tested it logging into Mango 2.5.2 via REST and it does receive the CORS headers in the response.
Enjoy,
TerryAttachment: download link
-
Terry,
Thank you very much.
Everything is now working as I had hoped.
Your help is greatly appreciated.
Gary
-
Spoke a little too soon. logout is generating a 401 Unauthorised error. I can live with that for now!
-
Gary,
Glad to hear it's working-ish. Can you give me some more information on the 401 error? If there is a bug in the current module I can make sure it is fixed for the next release. Preferably you could post the Logfile output otherwise just give a detailed explanation so I can reproduce it on my end.
Thanks,
Terry -
Unfortunately I am unable to reproduce the problem. I have not modified my code since Friday when I had this issue.
I have attached a section from ma.log timed just before I posted about the 401 error. I can't see anywhere within this that tells me the HTTP status code returned so I hope it is relevant.
I came across the 401 when clicking the 'log out' button in my application did nothing. I opened the developer tools in Chrome and immediately saw the error in the console. At the time, I was able to reproduce the error by refreshing the page, logging in and attempting to log out.
My application uses POST to /rest/v1/login/ and /rest/v1/logout/. The implementation details mirror MangoApi.js which I have been using as a reference implementation.
Attachment: download link
-
Terry,
I have replicated the 401 error and found the cause. When this error occured, the response headers contain the field 'errors' with a value 'User not logged in'. After a little bit of experimenting, I have worked out what I did to cause this.
To replicate:
Using Chrome*, open the Mango web interface and log in.
Open in another tab of the same window, a web application that utilised the Mango API and log in.
Separate the two tabs into different browser windows.
Log out from the web application and you will receive the 401 error.*I haven't tried other browsers.
Explanation:
The two tabs utilise the same session cookie. The cookie must be associated with one of the two browser windows when the separation occurs. The domain of this cookie matches the domain in the address bar of the mango web interface so the browser understandably associates that cookie with the Mango web interface, not the web application. Now the web application does not have a log-in cookie.
Possible answers:
- Don't do that.
- Have the Mango API deliver a different cookie.
- Set an expiry time on the cookie.
For me #2 is preferable but that may not play well with custom dashboards.
Gary
