I'm trying to troubleshoot an issue with uploading attachments to our internal Redmine site through Pulse VPN.
The upload form works internally, but when going through the pulse website, I keep getting a 422 webpage status with an "Invalid form authenticity token" error.
It appears that when a user reaches the attachment upload page, their login status to the redmine site is no longer active and they need to sign in again.
When scrubbing through the network log on my browser during troubleshooting, I'm finding the 422 web page status occuring during a POST method with the following details (private information has been replaced):
I've been playing with the autopolicies for the web bookmark in the Junos Pulse Secure Access Service web UI, but can't seem to get past this error. I've tested many forms of caching, Java Access Control, and Single sign-on settings for the bookmark as well as using Chrome, IE, & Firefox to troubleshoot.
I'm not too familiar with how these sorts of bookmarks requiring separate credentials are handled in Pulse, so any help or insight would be greatly appreciated. Thank you in advance.
Solved! Go to Solution.
For comparison, here is what the post method looks like when it works correctly (when visiting the redmine site internally without using the Pulse VPN site):
Its going to be hard to resolve this without understanding the impact of the Rewrite engine on this application. If you are familiar with web development technologies then can you capture a dsrecord (session recording) while replicating the issue? Then open the file and see if the POST request is sent as a HEAD request to the backend.? If yes then check if your backend app server supports the HEAD method?
Alternatively you should capture the following logs and open a JTAC case.
Thanks for your assistance. After much research, it came down to an issue with how rails authenticates sessions at different web pages.
Because the site is only used internally and users must authenticate before getting to the attachment upload page, we were able to safely disable re-authentication during the POST request in order to bypass the error we were getting.
We no longer receive the error through pulse after disabling the authenticity token check for the attachment controller on the redmine site as found here:
Thanks for sharing the URL. Is this for an app that is written in Ruby on Rails?
Was the AUTH method NTLM and POST body greater than 4k? In that case your issue sounds like the behaviour described in http://kb.pulsesecure.net/InfoCenter/index?page=content&id=KB17485 specifically the below part:
"Before 6.5R4 this technique of using 'HEAD' requests was restricted only to situations where the POST body is greater than 4k approximately (AND) for sites that the SA knows (by ÔlearningÕ during a previous HTTP transaction) is protected by NTLM authentication. The ÔHEADÕ method is used to send NTLM Type 1 message. This behavior of using ÔHEADÕ requests when a large body POST is encountered for NTLM protected web pages was introduced in 6.2R1 and since then has not been changed in any release to date (as of writing this article i.e. 7.0Rx). Therefore, if your backend resource is protected by ÔNTLMÕ authentication and involves large ÔPOSTÕ, then we recommend that you enable the support for http ÔHEADÕ method on your backend webserver."