Rest API 1.3.6 Broke Something

I installed the 1.3.6 plugin on my server upon notice of the version update via admin tool and XMPP chat client. Upon update I encountered issues with CORS Access-Control-Allow-Origin header missing. Prior to that version 1.3.5 had no issues, specifically when accessing the following from an angular application via converse.js:

https://<server_name>:9091/plugins/restapi/v1/users?search=<user>

Once the issue occurred I reverted to version 1.3.0 via stopping the server, deleting the plugin from the server plugin directory, building locally from source code tag v4.2.3, and upload plugin from the admin console.

This works fine, I’m sure that the same is true for 1.3.5.
Is this a regression?
Are other users experiencing this issue?

We observed something similar recently where a change in ordering of the container request filters caused authentication to effected. I think the ordering of the GZIP after CORS Filter might be related.

cc @Redeyes

@dbh That could the problem yes. But in 1.3.5 it would be also broken (because I didn’t changed that)

Thanks, I will investigate this further but at present in build version 1.3.0 the following headers are returned on the GET response for plugins/restapi/v1/users?search=username:

-Access-Control-Allow-Credentials: true
-Access-Control-Allow-Headers: origin, content-type, accept, authorization
-Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
-Access-Control-Allow-Origin: *

The same call in update version 1.3.6 has none of these causing a ‘No Access-Control-Allow-Origin’ error on Chrome, Firefox, and Safari.

Agreed. This must have crept in prior to 1.3.6 and is certainly not fixed by the change we made there.

Is there an external tool or client which makes it easy to duplicate the problem?

curl? https://curl.haxx.se/docs/manpage.html

@rfostersbr please confirm the below looks like you’re expecting. If so, I don’t mind making this fix.

It easy enough to play with, I’m testing using curl as @gdt suggested
Note: I also tested that authentication is working as expected after making this local code tweak.
When I change the order of the filters as I suggested here are the headers I get

$ curl -i --user dharrison:REDACTED http://bogus.davidbharrison.com:9090/plugins/restapi/v1/users?search=dharrison
HTTP/1.1 200 OK
Date: Fri, 31 Aug 2018 16:09:07 GMT
Set-Cookie: JSESSIONID=z5q4nbq1zx6g3bwx2y85bhfx;Path=/;HttpOnly
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: same
Content-Type: application/xml
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: origin, content-type, accept, authorization
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
Content-Length: 1845

@Redeyes, @gdt What level of testing would we want before creating a PR for the fix?

We defently need to ensure that all features are working as expected:

  • CORS feature
  • Authentication
  • Gzip

I’m certainly open to other ideas.

What I’m finding is that the implementation and version of JAX-RS used is extremely sensitive to the order of those Container Response Filters. It seems to treat them with equal priority and GZIP’s placement in the sequence causes one of the others (or itself) not to work. Unless someone knows of an easy way to explicitly set the priority or order with the older jax-rs, I’d look into upgrading the library to take advantage of new features in this area.

Version 2.x introduced the notion of Container Response Filter Priorities, set either by annotation, or specified when adding the filter.

Authentication should get Priorities.AUTHORIZATION (2000)
CORS should probably get Priorities.HEADER_DECORATOR (3000) (will check)
Gzip should probably get Priorities.ENTITY_CODER (4000) (will check)

Thoughts?

I would like to have it (jersey v2), but upgrade isn’t sad easy and would take time.

Theoretically, would there be any problem with rest API plugin upgrading/rewriting for Jersey v2, while the rest of openfire (base + plugins) remain unchanged?

I don’t see any problems with that. The REST API Client (java) is already in jersey v2

I’m less optimistic; it may be that there is a classpath clash between core Openfire and the plugin. It may well work, but I wouldn’t be surprised if it didn’t.

Greg

I have cors issue with 1.3.9. i have used restapi user search in conversejs. can you help me?