Calls to API result in 500 Error

This is kind of a nasty one!

I am trying to work with the Leads API on a clean install of OroCRM Tag 1.8.2 in production mode.

If I start up a new Browser(opening the app, not a new tab or window) and log in, everything works fine.

If I then go to /api/doc/ and make an API call to add a Lead, the Lead is created successfully and returns 201 with json of the created id.

Then, when I try go to(or reload) /lead in the UI to see then new lead that was created, I get a 500 error and a blank page(Chrome & Safari), in Firefox I get a red flash message that says “Sorry, page was not loaded correctly.” and the UI stays where it was.

No matter what I do at this point, the app does not respond at any URL while using the browser that initiated the call. If I quit the Browser and restart it, all is well again, all URLs responding. Also, if I log in with a different browser and hit /lead, it responds, so this issue just kills the browser that is being used to make the API call(or so it seems).

In the nginx error log, I have an entry for every URL I’ve tried to hit that looks something like this:

PHP message: PHP Fatal error: Call to a member function getId() on null in /var/www/vhosts/orocrm/vendor/oro/platform/src/Oro/Bundle/SecurityBundle/Http/Firewall/ContextListener.php on line 46

That’s what I know!

Topic

[ignatParticipant]

Hi Tom,

Did you pass any WSSE-related headers in these API requests?

Seems to me like an issue of WSSE authentication breaking existing session of logged in user. I think there was a similar issue a while ago. Based on your post it still exists. If this is the case I’ll create a bug and follow up when it will be fixed.

As a temporary solution at this moment you could use different browser session to send API requests through /api/doc/. Another option is to pass header with value “X-CSRF-Header: 1” in your API request instead of passing WSSE headers. This trick should work only in case if you are sending API request in browser while your user is logged in to Oro in same browser session.

Thanks,
Ignat

[Tom HollandParticipant]

Hi ignat,

I had not passed headers in the example I was talking about, but it seems to do the same thing whether I do or don’t.

I just tried the following, is this behavior is correct?

• Restart Browser, Login and go to api/doc

• Set the select items at the top of the page to – authentication: none body format: Form Data request format: json

• Twirl open OPTIONS /api/rest/{version}/.{_format}
• Click on Sandbox
• Click on Try! without entering anything additional
• Get 401 Unauthorized
• Reload the page(it does reload)

• Set authentication: WSSE body format: Form Data request format: json
• Click on Try!(OPTIONS Sandbox as above) without entering anything additional
• Get 200 OK with JSON Body returned
• Reload the page – failed, blank white screen. Restart Browser, login and go to api/doc

• Set authentication: none body format: Form Data request format: json
• Generate WSSE headers and put them in the form (OPTIONS Sandbox as above)
• Click on Try!
• Get 200 OK with JSON Body returned
• Reload the page – failed, blank white screen. Restart Browser, login and go to api/doc

• Set authentication: WSSE body format: Form Data request format: json
• Generate WSSE headers and put them in the form (OPTIONS Sandbox as above)
• Click on Try!
• Get 200 OK with JSON Body returned
• Reload the page – failed, blank white screen.

If the authorization is set to WSSE, does that mean that Oro is supposed to generate headers for you(as logged in user) and if authorization is set to none that you have to generate the headers?

In the case I just tried, it didn’t matter if I chose WSSE or none, when I entered freshly generated WSSE headers I got back a 200 with the proper json response and both cases caused blank screens on reload.

Using “X-CSRF-Header: 1” with authentication: none appears to be a workaround, however using “X-CSRF-Header: 1” with authentication: WSSE results in the same white screen on reload. This is kind of a bummer, because if you forget to set authentication: none(WSSE is default) at the top of the page, you get killed and have to restart.

I was relieved to find that the issue only kills the browser I am using and doesn’t affect the app’s performance for other users. It’s an inconvenience, definitely not a showstopper. Thank you for providing the workaround!

Thanks again,
Tom

[ignatParticipant]

Hi Tom,

This behavior is not correct. As you described when you either choose WSSE authentication or pass WSSE headers manually your current user login session will be broken in same browser. WSSE authentication option just generates these WSSE headers for you.

I’ll create a bug for that and follow up when it will be fixed. At the moment please consider to use one of 2 workarounds:
1) use api/doc in another browser session
2) use authentication “none” and pass header X-CSRF-Header: 1

Thanks,
Ignat

[Tom HollandParticipant]

Thanks for clarifying Ignat!

[Author]

Replies