[Apiman-user] CORS issue

[Marc Savy]

Thanks, I'll try to check that out EAP config issue and endeavour to roll
it into the next release (which should be done shortly).

https://issues.jboss.org/browse/APIMAN-1286

I can't think of any deliberate changes to the policy engine between
1.2.8.Final and 1.3.1.Final, so if you discover something untoward please
let me know.

On 27 September 2017 at 16:29, Scott Elliott <scottpelliott at gmail.com>
wrote:

> OK, I tried 1.3.1.  Looks like the EAP 7.0 standalone-apiman.xml was not
> updated to support the Keycloak changes.  I used the Wildfly version of the
> xml file to get it running.  However, now it looks like something is wrong
> with our internal policy plugins that worked in 1.2.8, so I'll have to
> debug that.
>
> Scott
>
> On Tue, Sep 26, 2017 at 4:46 PM Marc Savy <marc.savy at redhat.com> wrote:
>
>> Hi Scott,
>>
>> This is a symptom of an issue that was fixed in the latest verions of
>> apiman, please upgrade to 1.3.1.Final if possible and let me know if
>> everything seems to be working fine.
>>
>> On 26 September 2017 at 17:15, Scott Elliott <scottpelliott at gmail.com>
>> wrote:
>>
>>> Something wrong with io.apiman.gateway.engine.
>>> beans.util.CaseInsensitiveStringMultiMap.  The response headers start
>>> off with:
>>>
>>> [Server=Jetty(9.2.19.v20160908), null, null, Date=Tue, 26 Sep 2017
>>> 16:08:00 GMT, null, Content-Type=text/html; charset=ISO-8859-1, null, null,
>>> null, X-RateMonitor-Limit=1000, null, WWW-Authenticate=Bearer
>>> realm="mytest", error="invalid_token", error_description="Token is not
>>> active", X-RateMonitor-Remaining=998, null, null, null,
>>> X-RateMonitor-Reset=3119, null, null, null, null, null, null, null, null,
>>> null, null, null, null, null, null, Cache-Control=must-revalidate,
>>> no-cache,no-store]
>>>
>>> and after the CORS headers are merged, it's:
>>>
>>> {Access-Control-Allow-Credentials => [true, Bearer realm="mytest",
>>> error="invalid_token", error_description="Token is not active"],
>>> Access-Control-Allow-Origin => [http://blah.com,
>>> Jetty(9.2.19.v20160908)], Cache-Control => [must-revalidate,no-cache,no-store],
>>> Content-Type => [text/html; charset=ISO-8859-1], Date => [Tue, 26 Sep 2017
>>> 16:08:00 GMT], Server => [Jetty(9.2.19.v20160908)], WWW-Authenticate =>
>>> [Bearer realm="mytest", error="invalid_token", error_description="Token is
>>> not active"], X-RateMonitor-Limit => [1000], X-RateMonitor-Remaining =>
>>> [998], X-RateMonitor-Reset => [3119]}
>>>
>>> The "Server" value and the Access-Control-Allow-Origin are somehow
>>> merged.
>>>
>>> On Tue, Sep 26, 2017 at 11:56 AM Scott Elliott <scottpelliott at gmail.com>
>>> wrote:
>>>
>>>> 1.2.8.Final
>>>>
>>>> On Tue, Sep 26, 2017 at 8:04 AM Marc Savy <marc.savy at redhat.com> wrote:
>>>>
>>>>> Hi Scott,
>>>>>
>>>>> Which version of Apiman are you using?
>>>>>
>>>>> Regards,
>>>>> Marc
>>>>>
>>>>> On 26 September 2017 at 00:10, Scott Elliott <scottpelliott at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Why, when the CORS policy plugin is used, do I get multiple
>>>>>> Access-Control-Allow-Origin headers in the response. From curl:
>>>>>>
>>>>>> Origin: http://blah.com
>>>>>>
>>>>>> Access-Control-Allow-Origin: http://blah.com
>>>>>> Access-Control-Allow-Origin: Jetty(9.2.19.v20160908)
>>>>>>
>>>>>> Chrome does not like the multiple headers, so the API request fails.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>>>
>>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170927/98f24b12/attachment-0001.html