From cmoulliard at redhat.com  Thu Aug  6 08:29:14 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 6 Aug 2015 14:29:14 +0200
Subject: [Apiman-user] ApiMan & Swagger Doc
Message-ID: <55C3531A.7010107@redhat.com>

Hi,

The APiman GUI Web Interface allows to add the Swagger JSON/YAML - 
Service Defintion 
(https://www.dropbox.com/s/rakl089j6ylzwg9/Screenshot%202015-08-06%2013.21.43.png?dl=0). 
Is it used by Apiman or only present for doc purpose ?

Response

[13:23:04] <jcechace>    ch007m, currently the late AFAIK
[13:23:07] <jcechace>    later *
[13:34:33] <msavy>    ch007m: presently it'll show you nice API docs 
based upon the swagger doc - however, we're looking at how we might 
evolve that in future
[13:34:56] <msavy>    e.g. testing the api

Question : Where can I see from the ApiMan the API docs based upon the 
swagger doc ?

Idea : As Swagger API allows to define authorization, that could be 
interesting to import the Swagger Doc of a service in order to generate 
the services.

Regards,

Charles

From marc.savy at redhat.com  Thu Aug  6 08:56:33 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 6 Aug 2015 13:56:33 +0100
Subject: [Apiman-user] ApiMan & Swagger Doc
In-Reply-To: <55C3531A.7010107@redhat.com>
References: <55C3531A.7010107@redhat.com>
Message-ID: <55C35981.9040607@redhat.com>

Hi Charles,

This blog post should give you an idea of what the current capabilities
of apiman plus swagger are:
http://www.apiman.io/blog/api-manager/swagger/service/ui/2015/06/02/swagger.html

I think what you're asking for falls under the 1.3 section of our
roadmap http://www.apiman.io/latest/roadmap.html

Regards,
Marc

On 06/08/2015 13:29, Charles Moulliard wrote:
> Hi,
>
> The APiman GUI Web Interface allows to add the Swagger JSON/YAML -
> Service Defintion
> (https://www.dropbox.com/s/rakl089j6ylzwg9/Screenshot%202015-08-06%2013.21.43.png?dl=0).
> Is it used by Apiman or only present for doc purpose ?
>
> Response
>
> [13:23:04] <jcechace>    ch007m, currently the late AFAIK
> [13:23:07] <jcechace>    later *
> [13:34:33] <msavy>    ch007m: presently it'll show you nice API docs
> based upon the swagger doc - however, we're looking at how we might
> evolve that in future
> [13:34:56] <msavy>    e.g. testing the api
>
> Question : Where can I see from the ApiMan the API docs based upon the
> swagger doc ?
>
> Idea : As Swagger API allows to define authorization, that could be
> interesting to import the Swagger Doc of a service in order to generate
> the services.
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Thu Aug  6 09:00:03 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 6 Aug 2015 09:00:03 -0400
Subject: [Apiman-user] ApiMan & Swagger Doc
In-Reply-To: <55C3531A.7010107@redhat.com>
References: <55C3531A.7010107@redhat.com>
Message-ID: <55C35A53.1060106@redhat.com>

Swagger is currently supported only to document a service.  So it can be 
added by the Service Provider via the Definition tab on the service.  It 
is then displayed on the "Search for a Service to Consume" area of the 
UI (where application developers go to find services they wish to 
consume).  Specifically it will be shown on the service details UI 
screen once an app developer has searched for and found the service.

We do want to use the swagger information in many other places.  One of 
the things we'll be doing shortly is re-implementing the old "Import 
Service(s)" functionality that we had in an early version but didn't 
make the transition from GWT to angularjs.  So importing from a swagger 
definition is a likely candidate.

Additionally, we will want to implement testing tools, where a service 
provider can ensure that the various policies she configured are working 
properly.  For that it will also be useful to have the swagger 
definition available.

-Eric

On 8/6/2015 8:29 AM, Charles Moulliard wrote:
> Hi,
>
> The APiman GUI Web Interface allows to add the Swagger JSON/YAML -
> Service Defintion
> (https://www.dropbox.com/s/rakl089j6ylzwg9/Screenshot%202015-08-06%2013.21.43.png?dl=0).
> Is it used by Apiman or only present for doc purpose ?
>
> Response
>
> [13:23:04] <jcechace>    ch007m, currently the late AFAIK
> [13:23:07] <jcechace>    later *
> [13:34:33] <msavy>    ch007m: presently it'll show you nice API docs
> based upon the swagger doc - however, we're looking at how we might
> evolve that in future
> [13:34:56] <msavy>    e.g. testing the api
>
> Question : Where can I see from the ApiMan the API docs based upon the
> swagger doc ?
>
> Idea : As Swagger API allows to define authorization, that could be
> interesting to import the Swagger Doc of a service in order to generate
> the services.
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Thu Aug  6 09:00:43 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 6 Aug 2015 09:00:43 -0400
Subject: [Apiman-user] ApiMan & Swagger Doc
In-Reply-To: <55C35981.9040607@redhat.com>
References: <55C3531A.7010107@redhat.com> <55C35981.9040607@redhat.com>
Message-ID: <55C35A7B.4090803@redhat.com>

This is a much more concise and equally accurate response. :)

-Eric

On 8/6/2015 8:56 AM, Marc Savy wrote:
> Hi Charles,
>
> This blog post should give you an idea of what the current capabilities
> of apiman plus swagger are:
> http://www.apiman.io/blog/api-manager/swagger/service/ui/2015/06/02/swagger.html
>
> I think what you're asking for falls under the 1.3 section of our
> roadmap http://www.apiman.io/latest/roadmap.html
>
> Regards,
> Marc
>
> On 06/08/2015 13:29, Charles Moulliard wrote:
>> Hi,
>>
>> The APiman GUI Web Interface allows to add the Swagger JSON/YAML -
>> Service Defintion
>> (https://www.dropbox.com/s/rakl089j6ylzwg9/Screenshot%202015-08-06%2013.21.43.png?dl=0).
>> Is it used by Apiman or only present for doc purpose ?
>>
>> Response
>>
>> [13:23:04] <jcechace>    ch007m, currently the late AFAIK
>> [13:23:07] <jcechace>    later *
>> [13:34:33] <msavy>    ch007m: presently it'll show you nice API docs
>> based upon the swagger doc - however, we're looking at how we might
>> evolve that in future
>> [13:34:56] <msavy>    e.g. testing the api
>>
>> Question : Where can I see from the ApiMan the API docs based upon the
>> swagger doc ?
>>
>> Idea : As Swagger API allows to define authorization, that could be
>> interesting to import the Swagger Doc of a service in order to generate
>> the services.
>>
>> Regards,
>>
>> Charles
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From cmoulliard at redhat.com  Fri Aug  7 05:09:02 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Fri, 7 Aug 2015 11:09:02 +0200
Subject: [Apiman-user] @timestamp field
Message-ID: <55C475AE.3090401@redhat.com>

Hi,

Do we have a @timestamp field into Elasticsearch db to plot histogram of 
the requests - 
https://www.dropbox.com/s/pnd7zh0rierbt9d/Screenshot%202015-08-07%2011.06.00.png?dl=0 
in Kibana ?

Regards,

-- 
Charles Moulliard
Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat
cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014
MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - 
Belgium
twitter: @cmoulliard <http://twitter.com/cmoulliard> | blog: 
cmoulliard.github.io <http://cmoulliard.github.io>
committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, 
jbpm, deltaspike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150807/511eb007/attachment-0001.html 

From msavy at redhat.com  Fri Aug  7 05:30:07 2015
From: msavy at redhat.com (Marc Savy)
Date: Fri, 7 Aug 2015 05:30:07 -0400 (EDT)
Subject: [Apiman-user] @timestamp field
In-Reply-To: <55C475AE.3090401@redhat.com>
References: <55C475AE.3090401@redhat.com>
Message-ID: <1722605782.8046255.1438939807810.JavaMail.zimbra@redhat.com>

To share my IRC response with everyone:

10:15 msavy:
there are a bunch of different timestamps
depends which one you want to use, really
perhaps requestStart is the best choice

To give some context, there are several timestamps we collecting, including requestStart/requestEnd, serviceStart/serviceEnd, etc. Which one makes most sense as a canonical @timestamp is up to you, but I'd think perhaps `requestStart` makes most sense.


----- Original Message -----
From: "Charles Moulliard" <cmoulliard at redhat.com>
To: apiman-user at lists.jboss.org
Sent: Friday, 7 August, 2015 10:09:02 AM
Subject: [Apiman-user] @timestamp field

Hi, 

Do we have a @timestamp field into Elasticsearch db to plot histogram of the requests - https://www.dropbox.com/s/pnd7zh0rierbt9d/Screenshot%202015-08-07%2011.06.00.png?dl=0 in Kibana ? 

Regards, 

-- 
Charles Moulliard 
Principal Solution Architect / JBoss Fuse Expert - Global Enablement @redhat 
cmoulliard at redhat.com | work: +31 205 65 12 84 | mobile: +32 473 604 014 
MC-Square Business "Stockholm", Leonardo Da Vincilaan 19, Diegem 1831 - Belgium 
twitter: @cmoulliard | blog: cmoulliard.github.io 
committer: apache camel, karaf, servicemix, hawtio, fabric8, drools, jbpm, deltaspike 

_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user

From eric.wittmann at redhat.com  Fri Aug  7 10:13:11 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 7 Aug 2015 10:13:11 -0400
Subject: [Apiman-user] @timestamp field
In-Reply-To: <1722605782.8046255.1438939807810.JavaMail.zimbra@redhat.com>
References: <55C475AE.3090401@redhat.com>
	<1722605782.8046255.1438939807810.JavaMail.zimbra@redhat.com>
Message-ID: <55C4BCF7.2010205@redhat.com>

+1 - all the existing date histogram style metrics in apiman go off the 
requestStart field.

For reference, the list of all fields stored in ES:

https://github.com/apiman/apiman/blob/master/gateway/engine/core/src/main/java/io/apiman/gateway/engine/metrics/RequestMetric.java#L33-L56

On 8/7/2015 5:30 AM, Marc Savy wrote:
> To share my IRC response with everyone:
>
> 10:15 msavy:
> there are a bunch of different timestamps
> depends which one you want to use, really
> perhaps requestStart is the best choice
>
> To give some context, there are several timestamps we collecting, including requestStart/requestEnd, serviceStart/serviceEnd, etc. Which one makes most sense as a canonical @timestamp is up to you, but I'd think perhaps `requestStart` makes most sense.
>
>
> ----- Original Message -----
> From: "Charles Moulliard" <cmoulliard at redhat.com>
> To: apiman-user at lists.jboss.org
> Sent: Friday, 7 August, 2015 10:09:02 AM
> Subject: [Apiman-user] @timestamp field
>
> Hi,
>
> Do we have a @timestamp field into Elasticsearch db to plot histogram of the requests - https://www.dropbox.com/s/pnd7zh0rierbt9d/Screenshot%202015-08-07%2011.06.00.png?dl=0 in Kibana ?
>
> Regards,
>

From fadiabdeen at gmail.com  Mon Aug 10 08:56:38 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 10 Aug 2015 08:56:38 -0400
Subject: [Apiman-user] Token is not active.
Message-ID: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>

I keep getting occasional "Token is not active." on they keycloak side
occasionally . its really frustrating , i cant figure out what could cause
this to happen. everything seems correct.

Is there caching between API Man and Keycloak i can turn off ?  Have anyone
seeen this behavior ?

Thanks,
Fadi
Express.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150810/69e9a10e/attachment.html 

From eric.wittmann at redhat.com  Mon Aug 10 13:00:54 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 10 Aug 2015 13:00:54 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
Message-ID: <55C8D8C6.8020203@redhat.com>

How often does this occur?  What is the result?

I assume this is triggering a re-login in the UI?

There is no caching on the apiman side.  However the tokens issued by 
keycloak to the apiman UI do have an expiration.  You could try logging 
into the keycloak auth admin UI and increasing the lifespan of the tokens.

Any more details you can provide would be great.

-Eric

On 8/10/2015 8:56 AM, Fadi Abdin wrote:
> I keep getting occasional "Token is not active." on they keycloak side
> occasionally . its really frustrating , i cant figure out what could
> cause this to happen. everything seems correct.
>
> Is there caching between API Man and Keycloak i can turn off ?  Have
> anyone seeen this behavior ?
>
> Thanks,
> Fadi
> Express.com
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From ijlal.hzt at gmail.com  Tue Aug 11 03:39:55 2015
From: ijlal.hzt at gmail.com (Ijlal EL HAZITI)
Date: Tue, 11 Aug 2015 09:39:55 +0200
Subject: [Apiman-user] how apiman handles errors
Message-ID: <CAAyScYmMQKRJzrNkyhdMEMbGd5yDqjV25D4h+PHr+YSdoO6YgA@mail.gmail.com>

Good morning,

I'd like to know how Apiman handles errors coming from the APIs.
I have Rest web Services, a ESB and Apiman on the top, no matter what  the
error generated by the Rest web service (404, 416, 412...) , Apiman always
displays an error code 500.

Why Apiman behaves this way? How can I have on apiman the same error codes
as those generated by the web service?

Thank you

-- 
Cordialement
IjlaL EL HAZITI

*Etudiant Ing?nieur Etudes et D?veloppement*

*UBO - Master Professionnel de d?veloppement ? l'offshore des SI*
*FSK  - Master Sp?cialis? Qualit? du Logiciel*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150811/b579a7de/attachment.html 

From marc.savy at redhat.com  Tue Aug 11 04:16:48 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 11 Aug 2015 09:16:48 +0100
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55C8D8C6.8020203@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com>
Message-ID: <55C9AF70.2030501@redhat.com>

I think this may pertain to the Keycloak OAuth2 token. In which case, I
provided Fadi with a version containing additional logging to see if we
could track the issue down.

It's not an issue I've ever been able to replicate, and we don't fiddle
with the token data in any way, so I don't really see how we could
affect things.

My only suggestions are to ensure that time is accurate on all of the
systems (NTP, Chronyd, etc), and I believe this has already been done.

On 10/08/2015 18:00, Eric Wittmann wrote:
> How often does this occur?  What is the result?
>
> I assume this is triggering a re-login in the UI?
>
> There is no caching on the apiman side.  However the tokens issued by
> keycloak to the apiman UI do have an expiration.  You could try logging
> into the keycloak auth admin UI and increasing the lifespan of the tokens.
>
> Any more details you can provide would be great.
>
> -Eric
>
> On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>> I keep getting occasional "Token is not active." on they keycloak side
>> occasionally . its really frustrating , i cant figure out what could
>> cause this to happen. everything seems correct.
>>
>> Is there caching between API Man and Keycloak i can turn off ?  Have
>> anyone seeen this behavior ?
>>
>> Thanks,
>> Fadi
>> Express.com
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Tue Aug 11 07:51:51 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 11 Aug 2015 07:51:51 -0400
Subject: [Apiman-user] how apiman handles errors
In-Reply-To: <CAAyScYmMQKRJzrNkyhdMEMbGd5yDqjV25D4h+PHr+YSdoO6YgA@mail.gmail.com>
References: <CAAyScYmMQKRJzrNkyhdMEMbGd5yDqjV25D4h+PHr+YSdoO6YgA@mail.gmail.com>
Message-ID: <55C9E1D7.5080502@redhat.com>

apiman is supposed to pass back whatever error message was returned by 
the back end service.  I think you're probably hitting up against this bug:

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

I am hoping to have that fixed in the next version.

-Eric

On 8/11/2015 3:39 AM, Ijlal EL HAZITI wrote:
> Good morning,
>
> I'd like to know how Apiman handles errors coming from the APIs.
> I have Rest web Services, a ESB and Apiman on the top, no matter what
>   the error generated by the Rest web service (404, 416, 412...) ,
> Apiman always displays an error code 500.
>
> Why Apiman behaves this way? How can I have on apiman the same error
> codes as those generated by the web service?
>
> Thank you
>
> --
> Cordialement
> IjlaL EL HAZITI
> *
> *
> *Etudiant Ing?nieur Etudes et D?veloppement*
> *UBO - Master Professionnel de d?veloppement ? l'offshore des SI
> *
> *FSK  - Master Sp?cialis? Qualit? du Logiciel*
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Wed Aug 12 15:23:44 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Wed, 12 Aug 2015 16:23:44 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55C9AF70.2030501@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
Message-ID: <CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>

hi all ,

I get this one too.

I don't know if i clicked on some button or link or just error arise from
another dimension.

*16:06:37,817 INFO*  [stdout] (default task-59) Updated plan: PlanBean
[organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
description=The Heavy Metal Universe, createdBy=admin, createdOn=2015-08-12
15:57:02.829, modifiedBy=admin, modifiedOn=2015-08-12 15:57:02.829],
id=soundsLikeAPlan, name=soundsLikeAPlan, description=454test,
createdBy=admin, createdOn=2015-08-12 15:59:41.355]
*16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
*16:09:27,427 ERROR*
[org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-28)
Failed to verify token: org.keycloak.VerificationException: Token is not
active.
    at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
[keycloak-core-1.2.0.Final.jar:1.2.0.Final]
    at org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
[keycloak-core-1.2.0.Final.jar:1.2.0.Final]
    at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
[keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
    at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
[keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
    at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
[keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
    at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
[keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
    at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
[keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
[keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
    at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
[undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
[undertow-core-1.1.0.Final.jar:1.1.0.Final]
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_45]
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_45]
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]





On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy at redhat.com> wrote:

> I think this may pertain to the Keycloak OAuth2 token. In which case, I
> provided Fadi with a version containing additional logging to see if we
> could track the issue down.
>
> It's not an issue I've ever been able to replicate, and we don't fiddle
> with the token data in any way, so I don't really see how we could
> affect things.
>
> My only suggestions are to ensure that time is accurate on all of the
> systems (NTP, Chronyd, etc), and I believe this has already been done.
>
> On 10/08/2015 18:00, Eric Wittmann wrote:
> > How often does this occur?  What is the result?
> >
> > I assume this is triggering a re-login in the UI?
> >
> > There is no caching on the apiman side.  However the tokens issued by
> > keycloak to the apiman UI do have an expiration.  You could try logging
> > into the keycloak auth admin UI and increasing the lifespan of the
> tokens.
> >
> > Any more details you can provide would be great.
> >
> > -Eric
> >
> > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
> >> I keep getting occasional "Token is not active." on they keycloak side
> >> occasionally . its really frustrating , i cant figure out what could
> >> cause this to happen. everything seems correct.
> >>
> >> Is there caching between API Man and Keycloak i can turn off ?  Have
> >> anyone seeen this behavior ?
> >>
> >> Thanks,
> >> Fadi
> >> Express.com
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
> _______________________________________________
> 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/20150812/435b6f4a/attachment-0001.html 

From eric.wittmann at redhat.com  Wed Aug 12 15:36:25 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 12 Aug 2015 15:36:25 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
Message-ID: <55CBA039.8040509@redhat.com>

Is this something you can reproduce?  Or just something that happened once?

What did you experience when this occurred?  Did you get sent to the 
login page?  Did you get a blank page?  Error in the UI?

-Eric

On 8/12/2015 3:23 PM, Helio Frota wrote:
> hi all ,
>
> I get this one too.
>
> I don't know if i clicked on some button or link or just error arise
> from another dimension.
>
> *16:06:37,817 INFO*  [stdout] (default task-59) Updated plan: PlanBean
> [organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
> description=The Heavy Metal Universe, createdBy=admin,
> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
> modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan,
> name=soundsLikeAPlan, description=454test, createdBy=admin,
> createdOn=2015-08-12 15:59:41.355]
> *16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
> *16:09:27,427 ERROR*
> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
> task-28) Failed to verify token: org.keycloak.VerificationException:
> Token is not active.
>      at
> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>      at
> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>      at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>      at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>      at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_45]
>      at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_45]
>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>
>
>
>
>
> On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I think this may pertain to the Keycloak OAuth2 token. In which case, I
>     provided Fadi with a version containing additional logging to see if we
>     could track the issue down.
>
>     It's not an issue I've ever been able to replicate, and we don't fiddle
>     with the token data in any way, so I don't really see how we could
>     affect things.
>
>     My only suggestions are to ensure that time is accurate on all of the
>     systems (NTP, Chronyd, etc), and I believe this has already been done.
>
>     On 10/08/2015 18:00, Eric Wittmann wrote:
>      > How often does this occur?  What is the result?
>      >
>      > I assume this is triggering a re-login in the UI?
>      >
>      > There is no caching on the apiman side.  However the tokens issued by
>      > keycloak to the apiman UI do have an expiration.  You could try
>     logging
>      > into the keycloak auth admin UI and increasing the lifespan of
>     the tokens.
>      >
>      > Any more details you can provide would be great.
>      >
>      > -Eric
>      >
>      > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>      >> I keep getting occasional "Token is not active." on they
>     keycloak side
>      >> occasionally . its really frustrating , i cant figure out what could
>      >> cause this to happen. everything seems correct.
>      >>
>      >> Is there caching between API Man and Keycloak i can turn off ?  Have
>      >> anyone seeen this behavior ?
>      >>
>      >> Thanks,
>      >> Fadi
>      >> Express.com
>      >>
>      >>
>      >> _______________________________________________
>      >> Apiman-user mailing list
>      >> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/apiman-user
>      >>
>      > _______________________________________________
>      > Apiman-user mailing list
>      > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/apiman-user
>      >
>
>     _______________________________________________
>     Apiman-user mailing list
>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Wed Aug 12 15:40:12 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Wed, 12 Aug 2015 16:40:12 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CBA039.8040509@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
Message-ID: <CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>

Is this something you can reproduce?  Or just something that happened once?

unfortunately no. just once.

What did you experience when this occurred?  Did you get sent to the login
page?  Did you get a blank page?  Error in the UI?

nothing, just navigating , clicking etc.. no blank page or error in the UI.








On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Is this something you can reproduce?  Or just something that happened once?
>
> What did you experience when this occurred?  Did you get sent to the login
> page?  Did you get a blank page?  Error in the UI?
>
> -Eric
>
> On 8/12/2015 3:23 PM, Helio Frota wrote:
>
>> hi all ,
>>
>> I get this one too.
>>
>> I don't know if i clicked on some button or link or just error arise
>> from another dimension.
>>
>> *16:06:37,817 INFO*  [stdout] (default task-59) Updated plan: PlanBean
>> [organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
>> description=The Heavy Metal Universe, createdBy=admin,
>> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
>> modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan,
>> name=soundsLikeAPlan, description=454test, createdBy=admin,
>> createdOn=2015-08-12 15:59:41.355]
>> *16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
>> *16:09:27,427 ERROR*
>>
>> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
>> task-28) Failed to verify token: org.keycloak.VerificationException:
>> Token is not active.
>>      at
>> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
>> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>      at
>> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
>> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>      at
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>      at
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>      at
>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>      at
>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [rt.jar:1.8.0_45]
>>      at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [rt.jar:1.8.0_45]
>>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>>
>>
>>
>>
>>
>> On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>     I think this may pertain to the Keycloak OAuth2 token. In which case,
>> I
>>     provided Fadi with a version containing additional logging to see if
>> we
>>     could track the issue down.
>>
>>     It's not an issue I've ever been able to replicate, and we don't
>> fiddle
>>     with the token data in any way, so I don't really see how we could
>>     affect things.
>>
>>     My only suggestions are to ensure that time is accurate on all of the
>>     systems (NTP, Chronyd, etc), and I believe this has already been done.
>>
>>     On 10/08/2015 18:00, Eric Wittmann wrote:
>>      > How often does this occur?  What is the result?
>>      >
>>      > I assume this is triggering a re-login in the UI?
>>      >
>>      > There is no caching on the apiman side.  However the tokens issued
>> by
>>      > keycloak to the apiman UI do have an expiration.  You could try
>>     logging
>>      > into the keycloak auth admin UI and increasing the lifespan of
>>     the tokens.
>>      >
>>      > Any more details you can provide would be great.
>>      >
>>      > -Eric
>>      >
>>      > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>      >> I keep getting occasional "Token is not active." on they
>>     keycloak side
>>      >> occasionally . its really frustrating , i cant figure out what
>> could
>>      >> cause this to happen. everything seems correct.
>>      >>
>>      >> Is there caching between API Man and Keycloak i can turn off ?
>> Have
>>      >> anyone seeen this behavior ?
>>      >>
>>      >> Thanks,
>>      >> Fadi
>>      >> Express.com
>>      >>
>>      >>
>>      >> _______________________________________________
>>      >> Apiman-user mailing list
>>      >> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>      >> https://lists.jboss.org/mailman/listinfo/apiman-user
>>      >>
>>      > _______________________________________________
>>      > Apiman-user mailing list
>>      > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>      > https://lists.jboss.org/mailman/listinfo/apiman-user
>>      >
>>
>>     _______________________________________________
>>     Apiman-user mailing list
>>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150812/963e4fbc/attachment-0001.html 

From 00hf11 at gmail.com  Wed Aug 12 15:46:14 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Wed, 12 Aug 2015 16:46:14 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
Message-ID: <CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>

*16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
*16:09:27,427 ERROR*
[org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-28)
Failed to verify token: org.keycloak.

almost 2 min of inactivity..

but i did a try with more minutes and no errors ...

*16:36*:09,869 INFO  [stdout] (default task-8) Got organization
HeavyMetalOrg: OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
description=The Heavy Metal Universe, createdBy=admin, createdOn=2015-08-12
15:57:02.829, modifiedBy=admin, modifiedOn=2015-08-12 15:57:02.829]
*16:42*:06,805 INFO  [stdout] (default task-9) Getting info for user admin



On Wed, Aug 12, 2015 at 4:40 PM, Helio Frota <00hf11 at gmail.com> wrote:

> Is this something you can reproduce?  Or just something that happened once?
>
> unfortunately no. just once.
>
> What did you experience when this occurred?  Did you get sent to the login
> page?  Did you get a blank page?  Error in the UI?
>
> nothing, just navigating , clicking etc.. no blank page or error in the UI.
>
>
>
>
>
>
>
>
> On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> Is this something you can reproduce?  Or just something that happened
>> once?
>>
>> What did you experience when this occurred?  Did you get sent to the
>> login page?  Did you get a blank page?  Error in the UI?
>>
>> -Eric
>>
>> On 8/12/2015 3:23 PM, Helio Frota wrote:
>>
>>> hi all ,
>>>
>>> I get this one too.
>>>
>>> I don't know if i clicked on some button or link or just error arise
>>> from another dimension.
>>>
>>> *16:06:37,817 INFO*  [stdout] (default task-59) Updated plan: PlanBean
>>> [organization=OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
>>> description=The Heavy Metal Universe, createdBy=admin,
>>> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
>>> modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan,
>>> name=soundsLikeAPlan, description=454test, createdBy=admin,
>>> createdOn=2015-08-12 15:59:41.355]
>>> *16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user
>>> admin
>>> *16:09:27,427 ERROR*
>>>
>>> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
>>> task-28) Failed to verify token: org.keycloak.VerificationException:
>>> Token is not active.
>>>      at
>>> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
>>> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
>>> [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
>>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
>>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
>>> [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
>>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
>>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>      at
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
>>> [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>>      at
>>>
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
>>> [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>>> [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>>      at
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> [rt.jar:1.8.0_45]
>>>      at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>> [rt.jar:1.8.0_45]
>>>      at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy <marc.savy at redhat.com
>>> <mailto:marc.savy at redhat.com>> wrote:
>>>
>>>     I think this may pertain to the Keycloak OAuth2 token. In which
>>> case, I
>>>     provided Fadi with a version containing additional logging to see if
>>> we
>>>     could track the issue down.
>>>
>>>     It's not an issue I've ever been able to replicate, and we don't
>>> fiddle
>>>     with the token data in any way, so I don't really see how we could
>>>     affect things.
>>>
>>>     My only suggestions are to ensure that time is accurate on all of the
>>>     systems (NTP, Chronyd, etc), and I believe this has already been
>>> done.
>>>
>>>     On 10/08/2015 18:00, Eric Wittmann wrote:
>>>      > How often does this occur?  What is the result?
>>>      >
>>>      > I assume this is triggering a re-login in the UI?
>>>      >
>>>      > There is no caching on the apiman side.  However the tokens
>>> issued by
>>>      > keycloak to the apiman UI do have an expiration.  You could try
>>>     logging
>>>      > into the keycloak auth admin UI and increasing the lifespan of
>>>     the tokens.
>>>      >
>>>      > Any more details you can provide would be great.
>>>      >
>>>      > -Eric
>>>      >
>>>      > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>>      >> I keep getting occasional "Token is not active." on they
>>>     keycloak side
>>>      >> occasionally . its really frustrating , i cant figure out what
>>> could
>>>      >> cause this to happen. everything seems correct.
>>>      >>
>>>      >> Is there caching between API Man and Keycloak i can turn off ?
>>> Have
>>>      >> anyone seeen this behavior ?
>>>      >>
>>>      >> Thanks,
>>>      >> Fadi
>>>      >> Express.com
>>>      >>
>>>      >>
>>>      >> _______________________________________________
>>>      >> Apiman-user mailing list
>>>      >> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>>      >> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>      >>
>>>      > _______________________________________________
>>>      > Apiman-user mailing list
>>>      > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>>      > https://lists.jboss.org/mailman/listinfo/apiman-user
>>>      >
>>>
>>>     _______________________________________________
>>>     Apiman-user mailing list
>>>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150812/2ae7003f/attachment.html 

From eric.wittmann at redhat.com  Thu Aug 13 07:57:33 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 13 Aug 2015 07:57:33 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
Message-ID: <55CC862D.1000100@redhat.com>

In all these cases the UI kept working OK?  Did you ever get any sort of 
failure in the UI?  Example: missing data, page load failure, etc?

-Eric

On 8/12/2015 3:46 PM, Helio Frota wrote:
> *16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
> *16:09:27,427 ERROR*
> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
> task-28) Failed to verify token: org.keycloak.
>
> almost 2 min of inactivity..
>
> but i did a try with more minutes and no errors ...
>
> *16:36*:09,869 INFO  [stdout] (default task-8) Got organization
> HeavyMetalOrg: OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
> description=The Heavy Metal Universe, createdBy=admin,
> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
> modifiedOn=2015-08-12 15:57:02.829]
> *16:42*:06,805 INFO  [stdout] (default task-9) Getting info for user admin
>
>
>
> On Wed, Aug 12, 2015 at 4:40 PM, Helio Frota <00hf11 at gmail.com
> <mailto:00hf11 at gmail.com>> wrote:
>
>     Is this something you can reproduce?  Or just something that
>     happened once?
>
>     unfortunately no. just once.
>
>     What did you experience when this occurred?  Did you get sent to the
>     login page?  Did you get a blank page?  Error in the UI?
>
>     nothing, just navigating , clicking etc.. no blank page or error in
>     the UI.
>
>
>
>
>
>
>
>
>     On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann
>     <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>
>         Is this something you can reproduce?  Or just something that
>         happened once?
>
>         What did you experience when this occurred?  Did you get sent to
>         the login page?  Did you get a blank page?  Error in the UI?
>
>         -Eric
>
>         On 8/12/2015 3:23 PM, Helio Frota wrote:
>
>             hi all ,
>
>             I get this one too.
>
>             I don't know if i clicked on some button or link or just
>             error arise
>             from another dimension.
>
>             *16:06:37,817 INFO*  [stdout] (default task-59) Updated
>             plan: PlanBean
>             [organization=OrganizationBean [id=HeavyMetalOrg,
>             name=HeavyMetalOrg,
>             description=The Heavy Metal Universe, createdBy=admin,
>             createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
>             modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan,
>             name=soundsLikeAPlan, description=454test, createdBy=admin,
>             createdOn=2015-08-12 15:59:41.355]
>             *16:07:56,984 INFO*  [stdout] (default task-6) Getting info
>             for user admin
>             *16:09:27,427 ERROR*
>
>             [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
>             task-28) Failed to verify token:
>             org.keycloak.VerificationException:
>             Token is not active.
>                   at
>             org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
>             [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
>             [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
>             [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
>             [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
>             [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
>             [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
>             [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>                   at
>             io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
>             [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>                   at
>             io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
>             [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>             [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>                   at
>             java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>             [rt.jar:1.8.0_45]
>                   at
>             java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>             [rt.jar:1.8.0_45]
>                   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>
>
>
>
>
>             On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy
>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>             wrote:
>
>                  I think this may pertain to the Keycloak OAuth2 token.
>             In which case, I
>                  provided Fadi with a version containing additional
>             logging to see if we
>                  could track the issue down.
>
>                  It's not an issue I've ever been able to replicate, and
>             we don't fiddle
>                  with the token data in any way, so I don't really see
>             how we could
>                  affect things.
>
>                  My only suggestions are to ensure that time is accurate
>             on all of the
>                  systems (NTP, Chronyd, etc), and I believe this has
>             already been done.
>
>                  On 10/08/2015 18:00, Eric Wittmann wrote:
>                   > How often does this occur?  What is the result?
>                   >
>                   > I assume this is triggering a re-login in the UI?
>                   >
>                   > There is no caching on the apiman side.  However the
>             tokens issued by
>                   > keycloak to the apiman UI do have an expiration.
>             You could try
>                  logging
>                   > into the keycloak auth admin UI and increasing the
>             lifespan of
>                  the tokens.
>                   >
>                   > Any more details you can provide would be great.
>                   >
>                   > -Eric
>                   >
>                   > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>                   >> I keep getting occasional "Token is not active." on
>             they
>                  keycloak side
>                   >> occasionally . its really frustrating , i cant
>             figure out what could
>                   >> cause this to happen. everything seems correct.
>                   >>
>                   >> Is there caching between API Man and Keycloak i can
>             turn off ?  Have
>                   >> anyone seeen this behavior ?
>                   >>
>                   >> Thanks,
>                   >> Fadi
>                   >> Express.com
>                   >>
>                   >>
>                   >> _______________________________________________
>                   >> Apiman-user mailing list
>                   >> Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   >> https://lists.jboss.org/mailman/listinfo/apiman-user
>                   >>
>                   > _______________________________________________
>                   > Apiman-user mailing list
>                   > Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > https://lists.jboss.org/mailman/listinfo/apiman-user
>                   >
>
>                  _______________________________________________
>                  Apiman-user mailing list
>             Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>             _______________________________________________
>             Apiman-user mailing list
>             Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Thu Aug 13 08:12:10 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 13 Aug 2015 13:12:10 +0100
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CC862D.1000100@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
	<55CC862D.1000100@redhat.com>
Message-ID: <55CC899A.5090308@redhat.com>

Hi,

I wonder if this is a manifestation of an old bug that was seen on
LiveOak: https://issues.jboss.org/browse/LIVEOAK-579 - it looks
remarkably similar in character.

You can see the relevant source code for the token here:
https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/representations/JsonWebToken.java#L84

You can see it's not very complex. So I'll be surprised if the problem
is with that side of things - but perhaps.

In the past I made a custom version of the keycloak plugin with
additional logging. I've updated it, and you can build it below. In the
case of the error it'll print out a bunch of information about the token
which may help us diagnose the issue (on your gateway machine):

git clone https://github.com/msavy/apiman-plugins.git
cd apiman-plugins/
git checkout -b keycloak-logging origin/keycloak-logging
mvn clean install

Now you should be able to load up this 1.1.6-SNAPSHOT version of the
plugin and try it out.

Regards,
Marc

On 13/08/2015 12:57, Eric Wittmann wrote:
> In all these cases the UI kept working OK?  Did you ever get any sort of
> failure in the UI?  Example: missing data, page load failure, etc?
>
> -Eric
>
> On 8/12/2015 3:46 PM, Helio Frota wrote:
>> *16:07:56,984 INFO*  [stdout] (default task-6) Getting info for user admin
>> *16:09:27,427 ERROR*
>> [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
>> task-28) Failed to verify token: org.keycloak.
>>
>> almost 2 min of inactivity..
>>
>> but i did a try with more minutes and no errors ...
>>
>> *16:36*:09,869 INFO  [stdout] (default task-8) Got organization
>> HeavyMetalOrg: OrganizationBean [id=HeavyMetalOrg, name=HeavyMetalOrg,
>> description=The Heavy Metal Universe, createdBy=admin,
>> createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
>> modifiedOn=2015-08-12 15:57:02.829]
>> *16:42*:06,805 INFO  [stdout] (default task-9) Getting info for user admin
>>
>>
>>
>> On Wed, Aug 12, 2015 at 4:40 PM, Helio Frota <00hf11 at gmail.com
>> <mailto:00hf11 at gmail.com>> wrote:
>>
>>      Is this something you can reproduce?  Or just something that
>>      happened once?
>>
>>      unfortunately no. just once.
>>
>>      What did you experience when this occurred?  Did you get sent to the
>>      login page?  Did you get a blank page?  Error in the UI?
>>
>>      nothing, just navigating , clicking etc.. no blank page or error in
>>      the UI.
>>
>>
>>
>>
>>
>>
>>
>>
>>      On Wed, Aug 12, 2015 at 4:36 PM, Eric Wittmann
>>      <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>          Is this something you can reproduce?  Or just something that
>>          happened once?
>>
>>          What did you experience when this occurred?  Did you get sent to
>>          the login page?  Did you get a blank page?  Error in the UI?
>>
>>          -Eric
>>
>>          On 8/12/2015 3:23 PM, Helio Frota wrote:
>>
>>              hi all ,
>>
>>              I get this one too.
>>
>>              I don't know if i clicked on some button or link or just
>>              error arise
>>              from another dimension.
>>
>>              *16:06:37,817 INFO*  [stdout] (default task-59) Updated
>>              plan: PlanBean
>>              [organization=OrganizationBean [id=HeavyMetalOrg,
>>              name=HeavyMetalOrg,
>>              description=The Heavy Metal Universe, createdBy=admin,
>>              createdOn=2015-08-12 15:57:02.829, modifiedBy=admin,
>>              modifiedOn=2015-08-12 15:57:02.829], id=soundsLikeAPlan,
>>              name=soundsLikeAPlan, description=454test, createdBy=admin,
>>              createdOn=2015-08-12 15:59:41.355]
>>              *16:07:56,984 INFO*  [stdout] (default task-6) Getting info
>>              for user admin
>>              *16:09:27,427 ERROR*
>>
>>              [org.keycloak.adapters.BearerTokenRequestAuthenticator] (default
>>              task-28) Failed to verify token:
>>              org.keycloak.VerificationException:
>>              Token is not active.
>>                    at
>>              org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:46)
>>              [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:16)
>>              [keycloak-core-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:67)
>>              [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:62)
>>              [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:45)
>>              [keycloak-adapter-core-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:114)
>>              [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:94)
>>              [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>                    at
>>              io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
>>              [keycloak-undertow-adapter-1.2.0.Final.jar:1.2.0.Final]
>>                    at
>>              io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
>>              [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
>>              [undertow-core-1.1.0.Final.jar:1.1.0.Final]
>>                    at
>>              java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>              [rt.jar:1.8.0_45]
>>                    at
>>              java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>              [rt.jar:1.8.0_45]
>>                    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>>
>>
>>
>>
>>
>>              On Tue, Aug 11, 2015 at 5:16 AM, Marc Savy
>>              <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>              <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>>              wrote:
>>
>>                   I think this may pertain to the Keycloak OAuth2 token.
>>              In which case, I
>>                   provided Fadi with a version containing additional
>>              logging to see if we
>>                   could track the issue down.
>>
>>                   It's not an issue I've ever been able to replicate, and
>>              we don't fiddle
>>                   with the token data in any way, so I don't really see
>>              how we could
>>                   affect things.
>>
>>                   My only suggestions are to ensure that time is accurate
>>              on all of the
>>                   systems (NTP, Chronyd, etc), and I believe this has
>>              already been done.
>>
>>                   On 10/08/2015 18:00, Eric Wittmann wrote:
>>                    > How often does this occur?  What is the result?
>>                    >
>>                    > I assume this is triggering a re-login in the UI?
>>                    >
>>                    > There is no caching on the apiman side.  However the
>>              tokens issued by
>>                    > keycloak to the apiman UI do have an expiration.
>>              You could try
>>                   logging
>>                    > into the keycloak auth admin UI and increasing the
>>              lifespan of
>>                   the tokens.
>>                    >
>>                    > Any more details you can provide would be great.
>>                    >
>>                    > -Eric
>>                    >
>>                    > On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>                    >> I keep getting occasional "Token is not active." on
>>              they
>>                   keycloak side
>>                    >> occasionally . its really frustrating , i cant
>>              figure out what could
>>                    >> cause this to happen. everything seems correct.
>>                    >>
>>                    >> Is there caching between API Man and Keycloak i can
>>              turn off ?  Have
>>                    >> anyone seeen this behavior ?
>>                    >>
>>                    >> Thanks,
>>                    >> Fadi
>>                    >> Express.com
>>                    >>
>>                    >>
>>                    >> _______________________________________________
>>                    >> Apiman-user mailing list
>>                    >> Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>
>>              <mailto:Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>>
>>                    >> https://lists.jboss.org/mailman/listinfo/apiman-user
>>                    >>
>>                    > _______________________________________________
>>                    > Apiman-user mailing list
>>                    > Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>
>>              <mailto:Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>>
>>                    > https://lists.jboss.org/mailman/listinfo/apiman-user
>>                    >
>>
>>                   _______________________________________________
>>                   Apiman-user mailing list
>>              Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>
>>              <mailto:Apiman-user at lists.jboss.org
>>              <mailto:Apiman-user at lists.jboss.org>>
>>              https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>>              _______________________________________________
>>              Apiman-user mailing list
>>              Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>              https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From 00hf11 at gmail.com  Thu Aug 13 08:12:17 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Thu, 13 Aug 2015 09:12:17 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CC862D.1000100@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
	<55CC862D.1000100@redhat.com>
Message-ID: <CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>

In all these cases the UI kept working OK?

Yes.

Did you ever get any sort of failure in the UI?

No.

Example: missing data, page load failure, etc?

No. nothing, I don't remember if i clicked on some button or link , or just
the stack trace arise by doing nothing.

Trying to catch this again ( i have no idea how, but trying )

For now, I noticed that from time to time this is executed:

GET http://localhost:8080/apimanui/rest/tokenRefresh
200 OK

apiman [9:04:28 AM]>>  Bearer token successfully refreshed: {
  "token": "eyJhbG ... long token here",
  "refreshPeriod": 240
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150813/f355d210/attachment.html 

From 00hf11 at gmail.com  Thu Aug 13 08:20:04 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Thu, 13 Aug 2015 09:20:04 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
	<55CC862D.1000100@redhat.com>
	<CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>
Message-ID: <CABv=XZWhNXp5Jdaho9f6tDi6ayyH_TH6UjdUf7U7SNeQPKa0VA@mail.gmail.com>

Hi Marc Savy ,

Thanks for the information.

Yes, looks similar to the liveoak old bug.


On Thu, Aug 13, 2015 at 9:12 AM, Helio Frota <00hf11 at gmail.com> wrote:

> In all these cases the UI kept working OK?
>
> Yes.
>
> Did you ever get any sort of failure in the UI?
>
> No.
>
> Example: missing data, page load failure, etc?
>
> No. nothing, I don't remember if i clicked on some button or link , or
> just the stack trace arise by doing nothing.
>
> Trying to catch this again ( i have no idea how, but trying )
>
> For now, I noticed that from time to time this is executed:
>
> GET http://localhost:8080/apimanui/rest/tokenRefresh
> 200 OK
>
> apiman [9:04:28 AM]>>  Bearer token successfully refreshed: {
>   "token": "eyJhbG ... long token here",
>   "refreshPeriod": 240
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150813/318f5e5f/attachment.html 

From marc.savy at redhat.com  Thu Aug 13 08:23:10 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 13 Aug 2015 13:23:10 +0100
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
Message-ID: <55CC8C2E.9010405@redhat.com>

Hi Fadi,

Are you referring to the Keycloak OAuth2 policy or the apiman UI? If
it's the former, then please refer to my other post in this thread in
which I've included a version with additional logging for you to use.

Regards,
Marc

On 10/08/2015 13:56, Fadi Abdin wrote:
> I keep getting occasional "Token is not active." on they keycloak side
> occasionally . its really frustrating , i cant figure out what could
> cause this to happen. everything seems correct.
>
> Is there caching between API Man and Keycloak i can turn off ?  Have
> anyone seeen this behavior ?
>
> Thanks,
> Fadi
> Express.com
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Thu Aug 13 08:24:31 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 13 Aug 2015 08:24:31 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
	<55CC862D.1000100@redhat.com>
	<CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>
Message-ID: <55CC8C7F.2070800@redhat.com>

OK so everything works but you sometimes see a stack trace.  The stack 
trace is coming from the keycloak auth adapter.  As long as everything 
else still works, I'd be inclined to either ignore it or report it to 
keycloak.

Periodic calls to http://localhost:8080/apimanui/rest/tokenRefresh are 
expected.  This is done to obtain a new auth token that can be used to 
make authenticated calls to the API Manager REST layer (from the UI). 
The auth token issued by keycloak expires after 2 minutes.

-Eric

On 8/13/2015 8:12 AM, Helio Frota wrote:
> In all these cases the UI kept working OK?
>
> Yes.
>
> Did you ever get any sort of failure in the UI?
>
> No.
>
> Example: missing data, page load failure, etc?
>
> No. nothing, I don't remember if i clicked on some button or link , or
> just the stack trace arise by doing nothing.
>
> Trying to catch this again ( i have no idea how, but trying )
>
> For now, I noticed that from time to time this is executed:
>
> GET http://localhost:8080/apimanui/rest/tokenRefresh
> 200 OK
>
> apiman [9:04:28 AM]>>  Bearer token successfully refreshed: {
>    "token": "eyJhbG ... long token here",
>    "refreshPeriod": 240
> }
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Thu Aug 13 08:33:56 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Thu, 13 Aug 2015 09:33:56 -0300
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CC8C7F.2070800@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABv=XZWMjZ4mWQv6yh9nMAqk602PS_WHz+W-yhfwzteLKwHzQg@mail.gmail.com>
	<55CBA039.8040509@redhat.com>
	<CABv=XZXtcMvo0OOY+ktMC+vDAtUMUU3_8R=pY_7_d4qTO7i9Gg@mail.gmail.com>
	<CABv=XZXN=-jmK-ttDW4k_dvTtn3LkmiK2F+7Tse+JT-nvkx8rA@mail.gmail.com>
	<55CC862D.1000100@redhat.com>
	<CABv=XZUkTEfvFoapxKtRi5O7OFM=UR+nPCt5=9LyCSHv_KMYCA@mail.gmail.com>
	<55CC8C7F.2070800@redhat.com>
Message-ID: <CABv=XZVD2F2yAtkftVXzE=afubb8=oo3mG+t84FUSSd916Os=Q@mail.gmail.com>

OK so everything works but you sometimes see a stack trace.  The stack
trace is coming from the keycloak auth adapter.  As long as everything else
still works, I'd be inclined to either ignore it or report it to keycloak.

Yes, you right.

Thanks again for all information.

On Thu, Aug 13, 2015 at 9:24 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> OK so everything works but you sometimes see a stack trace.  The stack
> trace is coming from the keycloak auth adapter.  As long as everything else
> still works, I'd be inclined to either ignore it or report it to keycloak.
>
> Periodic calls to http://localhost:8080/apimanui/rest/tokenRefresh are
> expected.  This is done to obtain a new auth token that can be used to make
> authenticated calls to the API Manager REST layer (from the UI). The auth
> token issued by keycloak expires after 2 minutes.
>
> -Eric
>
>
> On 8/13/2015 8:12 AM, Helio Frota wrote:
>
>> In all these cases the UI kept working OK?
>>
>> Yes.
>>
>> Did you ever get any sort of failure in the UI?
>>
>> No.
>>
>> Example: missing data, page load failure, etc?
>>
>> No. nothing, I don't remember if i clicked on some button or link , or
>> just the stack trace arise by doing nothing.
>>
>> Trying to catch this again ( i have no idea how, but trying )
>>
>> For now, I noticed that from time to time this is executed:
>>
>> GET http://localhost:8080/apimanui/rest/tokenRefresh
>> 200 OK
>>
>> apiman [9:04:28 AM]>>  Bearer token successfully refreshed: {
>>    "token": "eyJhbG ... long token here",
>>    "refreshPeriod": 240
>> }
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150813/533f9bc2/attachment.html 

From fadiabdeen at gmail.com  Thu Aug 13 11:52:10 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 13 Aug 2015 11:52:10 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55C9AF70.2030501@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
Message-ID: <CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>

Marc / Eric,

Thank you for your help in the past , i really appreciate it . but my issue
did not get resolved yet .

My Application is really simple , i get a token from keycloak and use that
token call API MAN services .

When the application is fresh installed , this problem does not happened
often , but once many users using it and over time , it will start
rejecting tokens with the "Token is not active" message .

for example if my service is on https://myserver.com/api-gateway/myservice
i pass a token like with an access_token parameter

 https://myserver.com/api-gateway/myservice?access_token=<token value>
some time it return a value and some times not . i'm always using a new
browser , so its not the cashing.

The only way to solve the issue is to restart keycloak/apiman , seems they
back in sync .

It started a small problem with dev , but now its expanding because our
product with the QA people and this escalating .. Is there a way you guys
can help us a little more ? is there a paid support ?

Thanks,



On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy at redhat.com> wrote:

> I think this may pertain to the Keycloak OAuth2 token. In which case, I
> provided Fadi with a version containing additional logging to see if we
> could track the issue down.
>
> It's not an issue I've ever been able to replicate, and we don't fiddle
> with the token data in any way, so I don't really see how we could
> affect things.
>
> My only suggestions are to ensure that time is accurate on all of the
> systems (NTP, Chronyd, etc), and I believe this has already been done.
>
>
> On 10/08/2015 18:00, Eric Wittmann wrote:
>
>> How often does this occur?  What is the result?
>>
>> I assume this is triggering a re-login in the UI?
>>
>> There is no caching on the apiman side.  However the tokens issued by
>> keycloak to the apiman UI do have an expiration.  You could try logging
>> into the keycloak auth admin UI and increasing the lifespan of the tokens.
>>
>> Any more details you can provide would be great.
>>
>> -Eric
>>
>> On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>
>>> I keep getting occasional "Token is not active." on they keycloak side
>>> occasionally . its really frustrating , i cant figure out what could
>>> cause this to happen. everything seems correct.
>>>
>>> Is there caching between API Man and Keycloak i can turn off ?  Have
>>> anyone seeen this behavior ?
>>>
>>> Thanks,
>>> Fadi
>>> Express.com
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>> _______________________________________________
>> 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/20150813/1f370b40/attachment.html 

From eric.wittmann at redhat.com  Thu Aug 13 13:20:14 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 13 Aug 2015 13:20:14 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
Message-ID: <55CCD1CE.9010705@redhat.com>

Fadi - we definitely do want to get to the bottom of this, so are happy 
to do what we can to help.

Hopefully Marc's version of the OAuth2 plugin will help generate some 
information we can use to track down the problem.

Can you please open a JIRA for this issue?  And please include as much 
information as you can, for example:

* Version of apiman
* Version of OAuth2 plugin
* Setup/configuration (example: is Keycloak on a separate server?)
* Any other environmental information you think might be relevant

Having a JIRA issue will help us keep track of our progress on this issue.

-Eric

On 8/13/2015 11:52 AM, Fadi Abdin wrote:
> Marc / Eric,
>
> Thank you for your help in the past , i really appreciate it . but my
> issue did not get resolved yet .
>
> My Application is really simple , i get a token from keycloak and use
> that token call API MAN services .
>
> When the application is fresh installed , this problem does not happened
> often , but once many users using it and over time , it will start
> rejecting tokens with the "Token is not active" message .
>
> for example if my service is on
> https://myserver.com/api-gateway/myservice i pass a token like with an
> access_token parameter
>
> https://myserver.com/api-gateway/myservice?access_token=<token value>
> some time it return a value and some times not . i'm always using a new
> browser , so its not the cashing.
>
> The only way to solve the issue is to restart keycloak/apiman , seems
> they back in sync .
>
> It started a small problem with dev , but now its expanding because our
> product with the QA people and this escalating .. Is there a way you
> guys can help us a little more ? is there a paid support ?
>
> Thanks,
>
>
>
> On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I think this may pertain to the Keycloak OAuth2 token. In which case, I
>     provided Fadi with a version containing additional logging to see if we
>     could track the issue down.
>
>     It's not an issue I've ever been able to replicate, and we don't fiddle
>     with the token data in any way, so I don't really see how we could
>     affect things.
>
>     My only suggestions are to ensure that time is accurate on all of the
>     systems (NTP, Chronyd, etc), and I believe this has already been done.
>
>
>     On 10/08/2015 18:00, Eric Wittmann wrote:
>
>         How often does this occur?  What is the result?
>
>         I assume this is triggering a re-login in the UI?
>
>         There is no caching on the apiman side.  However the tokens
>         issued by
>         keycloak to the apiman UI do have an expiration.  You could try
>         logging
>         into the keycloak auth admin UI and increasing the lifespan of
>         the tokens.
>
>         Any more details you can provide would be great.
>
>         -Eric
>
>         On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>
>             I keep getting occasional "Token is not active." on they
>             keycloak side
>             occasionally . its really frustrating , i cant figure out
>             what could
>             cause this to happen. everything seems correct.
>
>             Is there caching between API Man and Keycloak i can turn off
>             ?  Have
>             anyone seeen this behavior ?
>
>             Thanks,
>             Fadi
>             Express.com
>
>
>             _______________________________________________
>             Apiman-user mailing list
>             Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>

From fadiabdeen at gmail.com  Fri Aug 14 11:47:21 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Fri, 14 Aug 2015 11:47:21 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CCD1CE.9010705@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
Message-ID: <CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>

I'm FINALLY ready to write a jira ticket , i think i'm able to identify the
what is happening

The logs coming in the policy prints the token information, I was surprised
to find that sometimes the token being sent is NOT the correct token I sent
to APIMan,

Example, If I hit a service with a token A , it prints the token B . Token
A is my token which is valid and i just got it , But token B is NOT even
mine and is expired from yesterday.

And this make sense to work after a restart , because it flushes all the
tokens and start fresh.

If there is a quick way to fix it , flush the tokens or whatever please let
me know .
I'm going to file a jira ticket , but i need things to work asap because we
are in QA now and going to production soon.



On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Fadi - we definitely do want to get to the bottom of this, so are happy to
> do what we can to help.
>
> Hopefully Marc's version of the OAuth2 plugin will help generate some
> information we can use to track down the problem.
>
> Can you please open a JIRA for this issue?  And please include as much
> information as you can, for example:
>
> * Version of apiman
> * Version of OAuth2 plugin
> * Setup/configuration (example: is Keycloak on a separate server?)
> * Any other environmental information you think might be relevant
>
> Having a JIRA issue will help us keep track of our progress on this issue.
>
> -Eric
>
> On 8/13/2015 11:52 AM, Fadi Abdin wrote:
>
>> Marc / Eric,
>>
>> Thank you for your help in the past , i really appreciate it . but my
>> issue did not get resolved yet .
>>
>> My Application is really simple , i get a token from keycloak and use
>> that token call API MAN services .
>>
>> When the application is fresh installed , this problem does not happened
>> often , but once many users using it and over time , it will start
>> rejecting tokens with the "Token is not active" message .
>>
>> for example if my service is on
>> https://myserver.com/api-gateway/myservice i pass a token like with an
>> access_token parameter
>>
>> https://myserver.com/api-gateway/myservice?access_token=<token value>
>> some time it return a value and some times not . i'm always using a new
>> browser , so its not the cashing.
>>
>> The only way to solve the issue is to restart keycloak/apiman , seems
>> they back in sync .
>>
>> It started a small problem with dev , but now its expanding because our
>> product with the QA people and this escalating .. Is there a way you
>> guys can help us a little more ? is there a paid support ?
>>
>> Thanks,
>>
>>
>>
>> On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>     I think this may pertain to the Keycloak OAuth2 token. In which case,
>> I
>>     provided Fadi with a version containing additional logging to see if
>> we
>>     could track the issue down.
>>
>>     It's not an issue I've ever been able to replicate, and we don't
>> fiddle
>>     with the token data in any way, so I don't really see how we could
>>     affect things.
>>
>>     My only suggestions are to ensure that time is accurate on all of the
>>     systems (NTP, Chronyd, etc), and I believe this has already been done.
>>
>>
>>     On 10/08/2015 18:00, Eric Wittmann wrote:
>>
>>         How often does this occur?  What is the result?
>>
>>         I assume this is triggering a re-login in the UI?
>>
>>         There is no caching on the apiman side.  However the tokens
>>         issued by
>>         keycloak to the apiman UI do have an expiration.  You could try
>>         logging
>>         into the keycloak auth admin UI and increasing the lifespan of
>>         the tokens.
>>
>>         Any more details you can provide would be great.
>>
>>         -Eric
>>
>>         On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>
>>             I keep getting occasional "Token is not active." on they
>>             keycloak side
>>             occasionally . its really frustrating , i cant figure out
>>             what could
>>             cause this to happen. everything seems correct.
>>
>>             Is there caching between API Man and Keycloak i can turn off
>>             ?  Have
>>             anyone seeen this behavior ?
>>
>>             Thanks,
>>             Fadi
>>             Express.com
>>
>>
>>             _______________________________________________
>>             Apiman-user mailing list
>>             Apiman-user at lists.jboss.org <mailto:
>> Apiman-user at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>         _______________________________________________
>>         Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto: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/20150814/62e0b97c/attachment-0001.html 

From marc.savy at redhat.com  Fri Aug 14 12:08:34 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 14 Aug 2015 17:08:34 +0100
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
	<CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
Message-ID: <55CE1282.9090605@redhat.com>

Hi Fadi,

Will be happy to investigate. Could you try another test for me, please?

Instead of setting the query parameter access_token, can you please instead use the Authorization header? This is a bit more resistant to some weirder forms of caching that might be going on in your pipeline.

Authorization: Bearer <token here>

Do *not* set the access_token query param.

In cURL you can do this by putting:

curl -v -H "Authorization: Bearer <token>" <url>

Regards,
Marc

On 14/08/2015 16:47, Fadi Abdin wrote:
> I'm FINALLY ready to write a jira ticket , i think i'm able to identify
> the what is happening
>
> The logs coming in the policy prints the token information, I was
> surprised to find that sometimes the token being sent is NOT the correct
> token I sent to APIMan,
>
> Example, If I hit a service with a token A , it prints the token B .
> Token A is my token which is valid and i just got it , But token B is
> NOT even mine and is expired from yesterday.
>
> And this make sense to work after a restart , because it flushes all the
> tokens and start fresh.
>
> If there is a quick way to fix it , flush the tokens or whatever please
> let me know .
> I'm going to file a jira ticket , but i need things to work asap because
> we are in QA now and going to production soon.
>
>
>
> On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Fadi - we definitely do want to get to the bottom of this, so are
>     happy to do what we can to help.
>
>     Hopefully Marc's version of the OAuth2 plugin will help generate
>     some information we can use to track down the problem.
>
>     Can you please open a JIRA for this issue?  And please include as
>     much information as you can, for example:
>
>     * Version of apiman
>     * Version of OAuth2 plugin
>     * Setup/configuration (example: is Keycloak on a separate server?)
>     * Any other environmental information you think might be relevant
>
>     Having a JIRA issue will help us keep track of our progress on this
>     issue.
>
>     -Eric
>
>     On 8/13/2015 11:52 AM, Fadi Abdin wrote:
>
>         Marc / Eric,
>
>         Thank you for your help in the past , i really appreciate it .
>         but my
>         issue did not get resolved yet .
>
>         My Application is really simple , i get a token from keycloak
>         and use
>         that token call API MAN services .
>
>         When the application is fresh installed , this problem does not
>         happened
>         often , but once many users using it and over time , it will start
>         rejecting tokens with the "Token is not active" message .
>
>         for example if my service is on
>         https://myserver.com/api-gateway/myservice i pass a token like
>         with an
>         access_token parameter
>
>         https://myserver.com/api-gateway/myservice?access_token=<token
>         value>
>         some time it return a value and some times not . i'm always
>         using a new
>         browser , so its not the cashing.
>
>         The only way to solve the issue is to restart keycloak/apiman ,
>         seems
>         they back in sync .
>
>         It started a small problem with dev , but now its expanding
>         because our
>         product with the QA people and this escalating .. Is there a way you
>         guys can help us a little more ? is there a paid support ?
>
>         Thanks,
>
>
>
>         On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>
>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>> wrote:
>
>              I think this may pertain to the Keycloak OAuth2 token. In
>         which case, I
>              provided Fadi with a version containing additional logging
>         to see if we
>              could track the issue down.
>
>              It's not an issue I've ever been able to replicate, and we
>         don't fiddle
>              with the token data in any way, so I don't really see how
>         we could
>              affect things.
>
>              My only suggestions are to ensure that time is accurate on
>         all of the
>              systems (NTP, Chronyd, etc), and I believe this has already
>         been done.
>
>
>              On 10/08/2015 18:00, Eric Wittmann wrote:
>
>                  How often does this occur?  What is the result?
>
>                  I assume this is triggering a re-login in the UI?
>
>                  There is no caching on the apiman side.  However the tokens
>                  issued by
>                  keycloak to the apiman UI do have an expiration.  You
>         could try
>                  logging
>                  into the keycloak auth admin UI and increasing the
>         lifespan of
>                  the tokens.
>
>                  Any more details you can provide would be great.
>
>                  -Eric
>
>                  On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>
>                      I keep getting occasional "Token is not active." on
>         they
>                      keycloak side
>                      occasionally . its really frustrating , i cant
>         figure out
>                      what could
>                      cause this to happen. everything seems correct.
>
>                      Is there caching between API Man and Keycloak i can
>         turn off
>                      ?  Have
>                      anyone seeen this behavior ?
>
>                      Thanks,
>                      Fadi
>                      Express.com
>
>
>                      _______________________________________________
>                      Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>                  _______________________________________________
>                  Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>


From eric.wittmann at redhat.com  Fri Aug 14 15:24:04 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 14 Aug 2015 15:24:04 -0400
Subject: [Apiman-user] Announcement: apiman 1.1.6.Final released
Message-ID: <55CE4054.10501@redhat.com>

What's new in this release?

* Quota policy (# of requests)
* Transfer quota policy (# of bytes)
* URL Rewriting policy
* Caching policy (use with care)
* Tech Preview: Vert.x 3 Gateway Impl (you'll need to build this 
yourself to try it!)
* Application Metrics
* (Optional) Send the Service Version in an HTTP Header instead of in 
the managed endpoint path

Of course we fixed a bunch of bugs too!

Have a look at the release notes:

https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12327699

Or as always go to the project site:

http://www.apiman.io/

-Eric

From kbabo at redhat.com  Fri Aug 14 15:40:59 2015
From: kbabo at redhat.com (Keith Babo)
Date: Fri, 14 Aug 2015 15:40:59 -0400
Subject: [Apiman-user] [Apiman-dev] Announcement: apiman 1.1.6.Final
	released
In-Reply-To: <55CE4054.10501@redhat.com>
References: <55CE4054.10501@redhat.com>
Message-ID: <302B402B-B5C5-4423-A8F6-74645A8969BC@redhat.com>

Nice!

~ keith

> On Aug 14, 2015, at 3:24 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> 
> What's new in this release?
> 
> * Quota policy (# of requests)
> * Transfer quota policy (# of bytes)
> * URL Rewriting policy
> * Caching policy (use with care)
> * Tech Preview: Vert.x 3 Gateway Impl (you'll need to build this 
> yourself to try it!)
> * Application Metrics
> * (Optional) Send the Service Version in an HTTP Header instead of in 
> the managed endpoint path
> 
> Of course we fixed a bunch of bugs too!
> 
> Have a look at the release notes:
> 
> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12327699
> 
> Or as always go to the project site:
> 
> http://www.apiman.io/
> 
> -Eric
> _______________________________________________
> Apiman-dev mailing list
> Apiman-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-dev



From fadiabdeen at gmail.com  Fri Aug 14 16:08:19 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Fri, 14 Aug 2015 16:08:19 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55CE1282.9090605@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
	<CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
	<55CE1282.9090605@redhat.com>
Message-ID: <CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>

I was only able to see the problem on the string parameter , but not the
bearer token when i use curl. that might do the trick for me after all the
struggle.

I'm having another problem with Bearer Token and CORS , thats why i'm not
using it and it works fine with the parameter .. I'll open another case for
this

On Fri, Aug 14, 2015 at 12:08 PM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi Fadi,
>
> Will be happy to investigate. Could you try another test for me, please?
>
> Instead of setting the query parameter access_token, can you please
> instead use the Authorization header? This is a bit more resistant to some
> weirder forms of caching that might be going on in your pipeline.
>
> Authorization: Bearer <token here>
>
> Do *not* set the access_token query param.
>
> In cURL you can do this by putting:
>
> curl -v -H "Authorization: Bearer <token>" <url>
>
> Regards,
> Marc
>
> On 14/08/2015 16:47, Fadi Abdin wrote:
>
>> I'm FINALLY ready to write a jira ticket , i think i'm able to identify
>> the what is happening
>>
>> The logs coming in the policy prints the token information, I was
>> surprised to find that sometimes the token being sent is NOT the correct
>> token I sent to APIMan,
>>
>> Example, If I hit a service with a token A , it prints the token B .
>> Token A is my token which is valid and i just got it , But token B is
>> NOT even mine and is expired from yesterday.
>>
>> And this make sense to work after a restart , because it flushes all the
>> tokens and start fresh.
>>
>> If there is a quick way to fix it , flush the tokens or whatever please
>> let me know .
>> I'm going to file a jira ticket , but i need things to work asap because
>> we are in QA now and going to production soon.
>>
>>
>>
>> On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>     Fadi - we definitely do want to get to the bottom of this, so are
>>     happy to do what we can to help.
>>
>>     Hopefully Marc's version of the OAuth2 plugin will help generate
>>     some information we can use to track down the problem.
>>
>>     Can you please open a JIRA for this issue?  And please include as
>>     much information as you can, for example:
>>
>>     * Version of apiman
>>     * Version of OAuth2 plugin
>>     * Setup/configuration (example: is Keycloak on a separate server?)
>>     * Any other environmental information you think might be relevant
>>
>>     Having a JIRA issue will help us keep track of our progress on this
>>     issue.
>>
>>     -Eric
>>
>>     On 8/13/2015 11:52 AM, Fadi Abdin wrote:
>>
>>         Marc / Eric,
>>
>>         Thank you for your help in the past , i really appreciate it .
>>         but my
>>         issue did not get resolved yet .
>>
>>         My Application is really simple , i get a token from keycloak
>>         and use
>>         that token call API MAN services .
>>
>>         When the application is fresh installed , this problem does not
>>         happened
>>         often , but once many users using it and over time , it will start
>>         rejecting tokens with the "Token is not active" message .
>>
>>         for example if my service is on
>>         https://myserver.com/api-gateway/myservice i pass a token like
>>         with an
>>         access_token parameter
>>
>>         https://myserver.com/api-gateway/myservice?access_token=<token
>>         value>
>>         some time it return a value and some times not . i'm always
>>         using a new
>>         browser , so its not the cashing.
>>
>>         The only way to solve the issue is to restart keycloak/apiman ,
>>         seems
>>         they back in sync .
>>
>>         It started a small problem with dev , but now its expanding
>>         because our
>>         product with the QA people and this escalating .. Is there a way
>> you
>>         guys can help us a little more ? is there a paid support ?
>>
>>         Thanks,
>>
>>
>>
>>         On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy <marc.savy at redhat.com
>>         <mailto:marc.savy at redhat.com>
>>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>> wrote:
>>
>>              I think this may pertain to the Keycloak OAuth2 token. In
>>         which case, I
>>              provided Fadi with a version containing additional logging
>>         to see if we
>>              could track the issue down.
>>
>>              It's not an issue I've ever been able to replicate, and we
>>         don't fiddle
>>              with the token data in any way, so I don't really see how
>>         we could
>>              affect things.
>>
>>              My only suggestions are to ensure that time is accurate on
>>         all of the
>>              systems (NTP, Chronyd, etc), and I believe this has already
>>         been done.
>>
>>
>>              On 10/08/2015 18:00, Eric Wittmann wrote:
>>
>>                  How often does this occur?  What is the result?
>>
>>                  I assume this is triggering a re-login in the UI?
>>
>>                  There is no caching on the apiman side.  However the
>> tokens
>>                  issued by
>>                  keycloak to the apiman UI do have an expiration.  You
>>         could try
>>                  logging
>>                  into the keycloak auth admin UI and increasing the
>>         lifespan of
>>                  the tokens.
>>
>>                  Any more details you can provide would be great.
>>
>>                  -Eric
>>
>>                  On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>
>>                      I keep getting occasional "Token is not active." on
>>         they
>>                      keycloak side
>>                      occasionally . its really frustrating , i cant
>>         figure out
>>                      what could
>>                      cause this to happen. everything seems correct.
>>
>>                      Is there caching between API Man and Keycloak i can
>>         turn off
>>                      ?  Have
>>                      anyone seeen this behavior ?
>>
>>                      Thanks,
>>                      Fadi
>>                      Express.com
>>
>>
>>                      _______________________________________________
>>                      Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>>
>>         https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>                  _______________________________________________
>>                  Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         <mailto:Apiman-user at lists.jboss.org
>>         <mailto: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/20150814/89880749/attachment-0001.html 

From 00hf11 at gmail.com  Fri Aug 14 18:46:45 2015
From: 00hf11 at gmail.com (Helio Frota)
Date: Fri, 14 Aug 2015 19:46:45 -0300
Subject: [Apiman-user] [Apiman-dev] Announcement: apiman 1.1.6.Final
	released
In-Reply-To: <302B402B-B5C5-4423-A8F6-74645A8969BC@redhat.com>
References: <55CE4054.10501@redhat.com>
	<302B402B-B5C5-4423-A8F6-74645A8969BC@redhat.com>
Message-ID: <CABv=XZWbWL7P+0LQuqGPf0Ac5mLn=0Y+90T4xJcCvuDWRgxT2A@mail.gmail.com>

great !


On Fri, Aug 14, 2015 at 4:40 PM, Keith Babo <kbabo at redhat.com> wrote:

> Nice!
>
> ~ keith
>
> > On Aug 14, 2015, at 3:24 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
> >
> > What's new in this release?
> >
> > * Quota policy (# of requests)
> > * Transfer quota policy (# of bytes)
> > * URL Rewriting policy
> > * Caching policy (use with care)
> > * Tech Preview: Vert.x 3 Gateway Impl (you'll need to build this
> > yourself to try it!)
> > * Application Metrics
> > * (Optional) Send the Service Version in an HTTP Header instead of in
> > the managed endpoint path
> >
> > Of course we fixed a bunch of bugs too!
> >
> > Have a look at the release notes:
> >
> >
> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12327699
> >
> > Or as always go to the project site:
> >
> > http://www.apiman.io/
> >
> > -Eric
> > _______________________________________________
> > Apiman-dev mailing list
> > Apiman-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-dev
>
>
> _______________________________________________
> Apiman-dev mailing list
> Apiman-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150814/ef1b501d/attachment.html 

From msavy at redhat.com  Sat Aug 15 04:20:21 2015
From: msavy at redhat.com (Marc Savy)
Date: Sat, 15 Aug 2015 04:20:21 -0400 (EDT)
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
	<CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
	<55CE1282.9090605@redhat.com>
	<CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>
Message-ID: <1941462689.12911212.1439626821029.JavaMail.zimbra@redhat.com>

Your issue with CORS Policy is possibly related to this - https://issues.jboss.org/browse/APIMAN-516 - I'll put that to the top of my list.

I tried running a script that did over 250,000 request-response cycles and didn't get any issues with OAuth2 and query parameters. This implies to me that it's a caching issue somewhere in your pipeline, but perhaps I'm not replicating your setup well enough.

----- Original Message -----
From: "Fadi Abdin" <fadiabdeen at gmail.com>
To: "Marc Savy" <marc.savy at redhat.com>
Cc: "apiman-user" <apiman-user at lists.jboss.org>
Sent: Friday, 14 August, 2015 9:08:19 PM
Subject: Re: [Apiman-user] Token is not active.

I was only able to see the problem on the string parameter , but not the bearer token when i use curl. that might do the trick for me after all the struggle. 

I'm having another problem with Bearer Token and CORS , thats why i'm not using it and it works fine with the parameter .. I'll open another case for this 

On Fri, Aug 14, 2015 at 12:08 PM, Marc Savy < marc.savy at redhat.com > wrote: 


Hi Fadi, 

Will be happy to investigate. Could you try another test for me, please? 

Instead of setting the query parameter access_token, can you please instead use the Authorization header? This is a bit more resistant to some weirder forms of caching that might be going on in your pipeline. 

Authorization: Bearer <token here> 

Do *not* set the access_token query param. 

In cURL you can do this by putting: 

curl -v -H "Authorization: Bearer <token>" <url> 

Regards, 
Marc 

On 14/08/2015 16:47, Fadi Abdin wrote: 


I'm FINALLY ready to write a jira ticket , i think i'm able to identify 
the what is happening 

The logs coming in the policy prints the token information, I was 
surprised to find that sometimes the token being sent is NOT the correct 
token I sent to APIMan, 

Example, If I hit a service with a token A , it prints the token B . 
Token A is my token which is valid and i just got it , But token B is 
NOT even mine and is expired from yesterday. 

And this make sense to work after a restart , because it flushes all the 
tokens and start fresh. 

If there is a quick way to fix it , flush the tokens or whatever please 
let me know . 
I'm going to file a jira ticket , but i need things to work asap because 
we are in QA now and going to production soon. 



On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann < eric.wittmann at redhat.com 
<mailto: eric.wittmann at redhat.com >> wrote: 

Fadi - we definitely do want to get to the bottom of this, so are 
happy to do what we can to help. 

Hopefully Marc's version of the OAuth2 plugin will help generate 
some information we can use to track down the problem. 

Can you please open a JIRA for this issue? And please include as 
much information as you can, for example: 

* Version of apiman 
* Version of OAuth2 plugin 
* Setup/configuration (example: is Keycloak on a separate server?) 
* Any other environmental information you think might be relevant 

Having a JIRA issue will help us keep track of our progress on this 
issue. 

-Eric 

On 8/13/2015 11:52 AM, Fadi Abdin wrote: 

Marc / Eric, 

Thank you for your help in the past , i really appreciate it . 
but my 
issue did not get resolved yet . 

My Application is really simple , i get a token from keycloak 
and use 
that token call API MAN services . 

When the application is fresh installed , this problem does not 
happened 
often , but once many users using it and over time , it will start 
rejecting tokens with the "Token is not active" message . 

for example if my service is on 
https://myserver.com/api-gateway/myservice i pass a token like 
with an 
access_token parameter 

https://myserver.com/api-gateway/myservice?access_token= <token 
value> 
some time it return a value and some times not . i'm always 
using a new 
browser , so its not the cashing. 

The only way to solve the issue is to restart keycloak/apiman , 
seems 
they back in sync . 

It started a small problem with dev , but now its expanding 
because our 
product with the QA people and this escalating .. Is there a way you 
guys can help us a little more ? is there a paid support ? 

Thanks, 



On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy < marc.savy at redhat.com 
<mailto: marc.savy at redhat.com > 
<mailto: marc.savy at redhat.com <mailto: marc.savy at redhat.com >>> wrote: 

I think this may pertain to the Keycloak OAuth2 token. In 
which case, I 
provided Fadi with a version containing additional logging 
to see if we 
could track the issue down. 

It's not an issue I've ever been able to replicate, and we 
don't fiddle 
with the token data in any way, so I don't really see how 
we could 
affect things. 

My only suggestions are to ensure that time is accurate on 
all of the 
systems (NTP, Chronyd, etc), and I believe this has already 
been done. 


On 10/08/2015 18:00, Eric Wittmann wrote: 

How often does this occur? What is the result? 

I assume this is triggering a re-login in the UI? 

There is no caching on the apiman side. However the tokens 
issued by 
keycloak to the apiman UI do have an expiration. You 
could try 
logging 
into the keycloak auth admin UI and increasing the 
lifespan of 
the tokens. 

Any more details you can provide would be great. 

-Eric 

On 8/10/2015 8:56 AM, Fadi Abdin wrote: 

I keep getting occasional "Token is not active." on 
they 
keycloak side 
occasionally . its really frustrating , i cant 
figure out 
what could 
cause this to happen. everything seems correct. 

Is there caching between API Man and Keycloak i can 
turn off 
? Have 
anyone seeen this behavior ? 

Thanks, 
Fadi 
Express.com 


_______________________________________________ 
Apiman-user mailing list 
Apiman-user at lists.jboss.org <mailto: Apiman-user at lists.jboss.org > 
<mailto: Apiman-user at lists.jboss.org 
<mailto: Apiman-user at lists.jboss.org >> 
https://lists.jboss.org/mailman/listinfo/apiman-user 

_______________________________________________ 
Apiman-user mailing list 
Apiman-user at lists.jboss.org <mailto: Apiman-user at lists.jboss.org > 
<mailto: Apiman-user at lists.jboss.org 
<mailto: Apiman-user at lists.jboss.org >> 
https://lists.jboss.org/mailman/listinfo/apiman-user 







_______________________________________________
Apiman-user mailing list
Apiman-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user

From cmoulliard at redhat.com  Mon Aug 17 02:10:49 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 17 Aug 2015 08:10:49 +0200
Subject: [Apiman-user] Announcement: apiman 1.1.6.Final released
In-Reply-To: <55CE4054.10501@redhat.com>
References: <55CE4054.10501@redhat.com>
Message-ID: <55D17AE9.1050205@redhat.com>

Excellent & great news.

On 14/08/15 21:24, Eric Wittmann wrote:
> What's new in this release?
>
> * Quota policy (# of requests)
> * Transfer quota policy (# of bytes)
> * URL Rewriting policy
> * Caching policy (use with care)
> * Tech Preview: Vert.x 3 Gateway Impl (you'll need to build this
> yourself to try it!)
> * Application Metrics
> * (Optional) Send the Service Version in an HTTP Header instead of in
> the managed endpoint path
>
> Of course we fixed a bunch of bugs too!
>
> Have a look at the release notes:
>
> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12314121&version=12327699
>
> Or as always go to the project site:
>
> http://www.apiman.io/
>
> -Eric
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From marc.savy at redhat.com  Mon Aug 17 07:15:19 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 17 Aug 2015 12:15:19 +0100
Subject: [Apiman-user] Token is not active.
In-Reply-To: <CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
	<CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
	<55CE1282.9090605@redhat.com>
	<CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>
Message-ID: <55D1C247.8010506@redhat.com>

Also, please provide feedback in the JIRA ticket, if you can -
https://issues.jboss.org/browse/APIMAN-623

You haven't provided enough detail for us to reconstruct your problem
(with regards to using query parameters).

On 14/08/2015 21:08, Fadi Abdin wrote:
> I was only able to see the problem on the string parameter , but not the
> bearer token when i use curl. that might do the trick for me after all
> the struggle.
>
> I'm having another problem with Bearer Token and CORS , thats why i'm
> not using it and it works fine with the parameter .. I'll open another
> case for this
>
> On Fri, Aug 14, 2015 at 12:08 PM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     Hi Fadi,
>
>     Will be happy to investigate. Could you try another test for me, please?
>
>     Instead of setting the query parameter access_token, can you please
>     instead use the Authorization header? This is a bit more resistant
>     to some weirder forms of caching that might be going on in your
>     pipeline.
>
>     Authorization: Bearer <token here>
>
>     Do *not* set the access_token query param.
>
>     In cURL you can do this by putting:
>
>     curl -v -H "Authorization: Bearer <token>" <url>
>
>     Regards,
>     Marc
>
>     On 14/08/2015 16:47, Fadi Abdin wrote:
>
>         I'm FINALLY ready to write a jira ticket , i think i'm able to
>         identify
>         the what is happening
>
>         The logs coming in the policy prints the token information, I was
>         surprised to find that sometimes the token being sent is NOT the
>         correct
>         token I sent to APIMan,
>
>         Example, If I hit a service with a token A , it prints the token B .
>         Token A is my token which is valid and i just got it , But token
>         B is
>         NOT even mine and is expired from yesterday.
>
>         And this make sense to work after a restart , because it flushes
>         all the
>         tokens and start fresh.
>
>         If there is a quick way to fix it , flush the tokens or whatever
>         please
>         let me know .
>         I'm going to file a jira ticket , but i need things to work asap
>         because
>         we are in QA now and going to production soon.
>
>
>
>         On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann
>         <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>
>         <mailto:eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>> wrote:
>
>              Fadi - we definitely do want to get to the bottom of this,
>         so are
>              happy to do what we can to help.
>
>              Hopefully Marc's version of the OAuth2 plugin will help
>         generate
>              some information we can use to track down the problem.
>
>              Can you please open a JIRA for this issue?  And please
>         include as
>              much information as you can, for example:
>
>              * Version of apiman
>              * Version of OAuth2 plugin
>              * Setup/configuration (example: is Keycloak on a separate
>         server?)
>              * Any other environmental information you think might be
>         relevant
>
>              Having a JIRA issue will help us keep track of our progress
>         on this
>              issue.
>
>              -Eric
>
>              On 8/13/2015 11:52 AM, Fadi Abdin wrote:
>
>                  Marc / Eric,
>
>                  Thank you for your help in the past , i really
>         appreciate it .
>                  but my
>                  issue did not get resolved yet .
>
>                  My Application is really simple , i get a token from
>         keycloak
>                  and use
>                  that token call API MAN services .
>
>                  When the application is fresh installed , this problem
>         does not
>                  happened
>                  often , but once many users using it and over time , it
>         will start
>                  rejecting tokens with the "Token is not active" message .
>
>                  for example if my service is on
>         https://myserver.com/api-gateway/myservice i pass a token like
>                  with an
>                  access_token parameter
>
>         https://myserver.com/api-gateway/myservice?access_token=<token
>                  value>
>                  some time it return a value and some times not . i'm always
>                  using a new
>                  browser , so its not the cashing.
>
>                  The only way to solve the issue is to restart
>         keycloak/apiman ,
>                  seems
>                  they back in sync .
>
>                  It started a small problem with dev , but now its expanding
>                  because our
>                  product with the QA people and this escalating .. Is
>         there a way you
>                  guys can help us a little more ? is there a paid support ?
>
>                  Thanks,
>
>
>
>                  On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy
>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                  <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>>> wrote:
>
>                       I think this may pertain to the Keycloak OAuth2
>         token. In
>                  which case, I
>                       provided Fadi with a version containing additional
>         logging
>                  to see if we
>                       could track the issue down.
>
>                       It's not an issue I've ever been able to
>         replicate, and we
>                  don't fiddle
>                       with the token data in any way, so I don't really
>         see how
>                  we could
>                       affect things.
>
>                       My only suggestions are to ensure that time is
>         accurate on
>                  all of the
>                       systems (NTP, Chronyd, etc), and I believe this
>         has already
>                  been done.
>
>
>                       On 10/08/2015 18:00, Eric Wittmann wrote:
>
>                           How often does this occur?  What is the result?
>
>                           I assume this is triggering a re-login in the UI?
>
>                           There is no caching on the apiman side.
>         However the tokens
>                           issued by
>                           keycloak to the apiman UI do have an
>         expiration.  You
>                  could try
>                           logging
>                           into the keycloak auth admin UI and increasing the
>                  lifespan of
>                           the tokens.
>
>                           Any more details you can provide would be great.
>
>                           -Eric
>
>                           On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>
>                               I keep getting occasional "Token is not
>         active." on
>                  they
>                               keycloak side
>                               occasionally . its really frustrating , i cant
>                  figure out
>                               what could
>                               cause this to happen. everything seems
>         correct.
>
>                               Is there caching between API Man and
>         Keycloak i can
>                  turn off
>                               ?  Have
>                               anyone seeen this behavior ?
>
>                               Thanks,
>                               Fadi
>                               Express.com
>
>
>
>           _______________________________________________
>                               Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>                  <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>                           _______________________________________________
>                           Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>                  <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>


From fadiabdeen at gmail.com  Mon Aug 17 08:57:17 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 17 Aug 2015 08:57:17 -0400
Subject: [Apiman-user] Token is not active.
In-Reply-To: <55D1C247.8010506@redhat.com>
References: <CABXXV0QJ6ORCgfkrxawebFdr0oJzBOf12FQvBJ-3H=N7M=VgkQ@mail.gmail.com>
	<55C8D8C6.8020203@redhat.com> <55C9AF70.2030501@redhat.com>
	<CABXXV0RehJZm4X7D+M6SuKPXsFyhwNugMeh7ds0p=kkOZwMw-Q@mail.gmail.com>
	<55CCD1CE.9010705@redhat.com>
	<CABXXV0ThbqMRP3Pz8T=EW1K7Wb4ft=auWAmaEqgBt=H0L2hR6A@mail.gmail.com>
	<55CE1282.9090605@redhat.com>
	<CABXXV0TPQhN_CKwSo-zt1dvP501LY3VsjXu+rfJ7BJ0uw=8pGw@mail.gmail.com>
	<55D1C247.8010506@redhat.com>
Message-ID: <CABXXV0QijQeyKEB_Q=Sx-Fx+9TWCcvVeDDiNGp8MevoA5ogoiw@mail.gmail.com>

Ok.

I'm also going to comment on the CORS Jira
https://issues.jboss.org/browse/APIMAN-516 . this might not be the same
issue i see.

On Mon, Aug 17, 2015 at 7:15 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Also, please provide feedback in the JIRA ticket, if you can -
> https://issues.jboss.org/browse/APIMAN-623
>
> You haven't provided enough detail for us to reconstruct your problem
> (with regards to using query parameters).
>
> On 14/08/2015 21:08, Fadi Abdin wrote:
>
>> I was only able to see the problem on the string parameter , but not the
>> bearer token when i use curl. that might do the trick for me after all
>> the struggle.
>>
>> I'm having another problem with Bearer Token and CORS , thats why i'm
>> not using it and it works fine with the parameter .. I'll open another
>> case for this
>>
>> On Fri, Aug 14, 2015 at 12:08 PM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>     Hi Fadi,
>>
>>     Will be happy to investigate. Could you try another test for me,
>> please?
>>
>>     Instead of setting the query parameter access_token, can you please
>>     instead use the Authorization header? This is a bit more resistant
>>     to some weirder forms of caching that might be going on in your
>>     pipeline.
>>
>>     Authorization: Bearer <token here>
>>
>>     Do *not* set the access_token query param.
>>
>>     In cURL you can do this by putting:
>>
>>     curl -v -H "Authorization: Bearer <token>" <url>
>>
>>     Regards,
>>     Marc
>>
>>     On 14/08/2015 16:47, Fadi Abdin wrote:
>>
>>         I'm FINALLY ready to write a jira ticket , i think i'm able to
>>         identify
>>         the what is happening
>>
>>         The logs coming in the policy prints the token information, I was
>>         surprised to find that sometimes the token being sent is NOT the
>>         correct
>>         token I sent to APIMan,
>>
>>         Example, If I hit a service with a token A , it prints the token
>> B .
>>         Token A is my token which is valid and i just got it , But token
>>         B is
>>         NOT even mine and is expired from yesterday.
>>
>>         And this make sense to work after a restart , because it flushes
>>         all the
>>         tokens and start fresh.
>>
>>         If there is a quick way to fix it , flush the tokens or whatever
>>         please
>>         let me know .
>>         I'm going to file a jira ticket , but i need things to work asap
>>         because
>>         we are in QA now and going to production soon.
>>
>>
>>
>>         On Thu, Aug 13, 2015 at 1:20 PM, Eric Wittmann
>>         <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>
>>         <mailto:eric.wittmann at redhat.com
>>
>>         <mailto:eric.wittmann at redhat.com>>> wrote:
>>
>>              Fadi - we definitely do want to get to the bottom of this,
>>         so are
>>              happy to do what we can to help.
>>
>>              Hopefully Marc's version of the OAuth2 plugin will help
>>         generate
>>              some information we can use to track down the problem.
>>
>>              Can you please open a JIRA for this issue?  And please
>>         include as
>>              much information as you can, for example:
>>
>>              * Version of apiman
>>              * Version of OAuth2 plugin
>>              * Setup/configuration (example: is Keycloak on a separate
>>         server?)
>>              * Any other environmental information you think might be
>>         relevant
>>
>>              Having a JIRA issue will help us keep track of our progress
>>         on this
>>              issue.
>>
>>              -Eric
>>
>>              On 8/13/2015 11:52 AM, Fadi Abdin wrote:
>>
>>                  Marc / Eric,
>>
>>                  Thank you for your help in the past , i really
>>         appreciate it .
>>                  but my
>>                  issue did not get resolved yet .
>>
>>                  My Application is really simple , i get a token from
>>         keycloak
>>                  and use
>>                  that token call API MAN services .
>>
>>                  When the application is fresh installed , this problem
>>         does not
>>                  happened
>>                  often , but once many users using it and over time , it
>>         will start
>>                  rejecting tokens with the "Token is not active" message .
>>
>>                  for example if my service is on
>>         https://myserver.com/api-gateway/myservice i pass a token like
>>                  with an
>>                  access_token parameter
>>
>>         https://myserver.com/api-gateway/myservice?access_token=<token
>>                  value>
>>                  some time it return a value and some times not . i'm
>> always
>>                  using a new
>>                  browser , so its not the cashing.
>>
>>                  The only way to solve the issue is to restart
>>         keycloak/apiman ,
>>                  seems
>>                  they back in sync .
>>
>>                  It started a small problem with dev , but now its
>> expanding
>>                  because our
>>                  product with the QA people and this escalating .. Is
>>         there a way you
>>                  guys can help us a little more ? is there a paid support
>> ?
>>
>>                  Thanks,
>>
>>
>>
>>                  On Tue, Aug 11, 2015 at 4:16 AM, Marc Savy
>>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>                  <mailto:marc.savy at redhat.com <mailto:
>> marc.savy at redhat.com>>
>>                  <mailto:marc.savy at redhat.com
>>         <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>         <mailto:marc.savy at redhat.com>>>> wrote:
>>
>>                       I think this may pertain to the Keycloak OAuth2
>>         token. In
>>                  which case, I
>>                       provided Fadi with a version containing additional
>>         logging
>>                  to see if we
>>                       could track the issue down.
>>
>>                       It's not an issue I've ever been able to
>>         replicate, and we
>>                  don't fiddle
>>                       with the token data in any way, so I don't really
>>         see how
>>                  we could
>>                       affect things.
>>
>>                       My only suggestions are to ensure that time is
>>         accurate on
>>                  all of the
>>                       systems (NTP, Chronyd, etc), and I believe this
>>         has already
>>                  been done.
>>
>>
>>                       On 10/08/2015 18:00, Eric Wittmann wrote:
>>
>>                           How often does this occur?  What is the result?
>>
>>                           I assume this is triggering a re-login in the
>> UI?
>>
>>                           There is no caching on the apiman side.
>>         However the tokens
>>                           issued by
>>                           keycloak to the apiman UI do have an
>>         expiration.  You
>>                  could try
>>                           logging
>>                           into the keycloak auth admin UI and increasing
>> the
>>                  lifespan of
>>                           the tokens.
>>
>>                           Any more details you can provide would be great.
>>
>>                           -Eric
>>
>>                           On 8/10/2015 8:56 AM, Fadi Abdin wrote:
>>
>>                               I keep getting occasional "Token is not
>>         active." on
>>                  they
>>                               keycloak side
>>                               occasionally . its really frustrating , i
>> cant
>>                  figure out
>>                               what could
>>                               cause this to happen. everything seems
>>         correct.
>>
>>                               Is there caching between API Man and
>>         Keycloak i can
>>                  turn off
>>                               ?  Have
>>                               anyone seeen this behavior ?
>>
>>                               Thanks,
>>                               Fadi
>>                               Express.com
>>
>>
>>
>>           _______________________________________________
>>                               Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>>
>>                  <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>
>>                  <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>>>
>>         https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>                           _______________________________________________
>>                           Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>>
>>                  <mailto:Apiman-user at lists.jboss.org
>>         <mailto:Apiman-user at lists.jboss.org>
>>                  <mailto:Apiman-user at lists.jboss.org
>>         <mailto: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/20150817/4e524171/attachment-0001.html 

From fadiabdeen at gmail.com  Mon Aug 17 10:44:43 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 17 Aug 2015 10:44:43 -0400
Subject: [Apiman-user] CORS
Message-ID: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>

I have a problem in calling a service in apiman-gateway with the
Authorization: Bearer <token> in the header.

It seems to preflight OPTIONS and return

   1. X-Policy-Failure-Message:
   OAuth2 'Authorization' header or 'access_token' query parameter must be
   provided.

I am sending the bearer token with the request and i make sure in the
preflight its sent in the request.


   1. Access-Control-Request-Headers:
   accept, authorization

Does anyone know if there Is something i'm missing ?  do i need to get
authorization enabled or added anywhere ? as a side note i have below in my
api as well:

response.setHeader("Access-Control-Allow-Headers", "Authorization");
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150817/74821f71/attachment.html 

From eric.wittmann at redhat.com  Mon Aug 17 10:51:51 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 17 Aug 2015 10:51:51 -0400
Subject: [Apiman-user] Note: DDL problems with apiman 1.1.6.Final
Message-ID: <55D1F507.90609@redhat.com>

Hey everyone.  There are a couple minor DDL problems (primarily in the 
postgres DDL) which snuck into version 1.1.6.Final.  I will fix these 
and get them committed to git so you can pull them down.  The ones that 
come with the 1.1.6.Final distribution will not work without some tweaks.

FYI!

-Eric

From marc.savy at redhat.com  Mon Aug 17 10:52:08 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 17 Aug 2015 15:52:08 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
Message-ID: <55D1F518.2080804@redhat.com>

Hi,

This is related to the JIRA I linked you to (https://issues.jboss.org/browse/APIMAN-516). Because of the way the policy chain currently works the behaviour of CORS is invalid in a few very specific cases (e.g. when you stack it with an auth policy). I'll let you know when it's fixed.

Regards,
Marc

On 17/08/2015 15:44, Fadi Abdin wrote:
> I have a problem in calling a service in apiman-gateway with the
> Authorization: Bearer <token> in the header.
>
> It seems to preflight OPTIONS and return
>
>  1.
>     X-Policy-Failure-Message:
>     OAuth2 'Authorization' header or 'access_token' query parameter must
>     be provided.
>
> I am sending the bearer token with the request and i make sure in the
> preflight its sent in the request.
>
>  1.
>     Access-Control-Request-Headers:
>     accept, authorization
>
> Does anyone know if there Is something i'm missing ?  do i need to get
> authorization enabled or added anywhere ? as a side note i have below in
> my api as well:
>
> response.setHeader("Access-Control-Allow-Headers", "Authorization");
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From fadiabdeen at gmail.com  Mon Aug 17 11:23:07 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 17 Aug 2015 11:23:07 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D1F518.2080804@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
Message-ID: <CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>

Thank you Marc,
Is there a work around that you can think of ?
I'm doing it with angularjs  , very simple

$http({method: 'GET', url: 'http://server/apiman-gateway/service', headers:
{
    'Authorization': 'Bearer XXXXXXXXXXXXX'}
});

I assume you will fix it in the new version , right?



On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy <marc.savy at redhat.com> wrote:

> Hi,
>
> This is related to the JIRA I linked you to (
> https://issues.jboss.org/browse/APIMAN-516). Because of the way the
> policy chain currently works the behaviour of CORS is invalid in a few very
> specific cases (e.g. when you stack it with an auth policy). I'll let you
> know when it's fixed.
>
> Regards,
> Marc
>
> On 17/08/2015 15:44, Fadi Abdin wrote:
>
>> I have a problem in calling a service in apiman-gateway with the
>> Authorization: Bearer <token> in the header.
>>
>> It seems to preflight OPTIONS and return
>>
>>  1.
>>     X-Policy-Failure-Message:
>>     OAuth2 'Authorization' header or 'access_token' query parameter must
>>     be provided.
>>
>> I am sending the bearer token with the request and i make sure in the
>> preflight its sent in the request.
>>
>>  1.
>>     Access-Control-Request-Headers:
>>     accept, authorization
>>
>> Does anyone know if there Is something i'm missing ?  do i need to get
>> authorization enabled or added anywhere ? as a side note i have below in
>> my api as well:
>>
>> response.setHeader("Access-Control-Allow-Headers", "Authorization");
>>
>>
>> _______________________________________________
>> 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/20150817/a01a1fa9/attachment.html 

From marc.savy at redhat.com  Mon Aug 17 11:37:17 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 17 Aug 2015 16:37:17 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
Message-ID: <55D1FFAD.3000201@redhat.com>

I'm actually testing the fix right now. It will land both on the 1.2.x
branch and the 1.1.x branch shortly. You should be able to test it out
in a short while: I'll send you an email when it's available.

On 17/08/2015 16:23, Fadi Abdin wrote:
> Thank you Marc,
> Is there a work around that you can think of ?
> I'm doing it with angularjs  , very simple
>
> $http({method: 'GET', url: 'http://server/apiman-gateway/service',
> headers: {
>      'Authorization': 'Bearer XXXXXXXXXXXXX'}
> });
>
> I assume you will fix it in the new version , right?
>
>
>
> On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     Hi,
>
>     This is related to the JIRA I linked you to
>     (https://issues.jboss.org/browse/APIMAN-516). Because of the way the
>     policy chain currently works the behaviour of CORS is invalid in a
>     few very specific cases (e.g. when you stack it with an auth
>     policy). I'll let you know when it's fixed.
>
>     Regards,
>     Marc
>
>     On 17/08/2015 15:44, Fadi Abdin wrote:
>
>         I have a problem in calling a service in apiman-gateway with the
>         Authorization: Bearer <token> in the header.
>
>         It seems to preflight OPTIONS and return
>
>           1.
>              X-Policy-Failure-Message:
>              OAuth2 'Authorization' header or 'access_token' query
>         parameter must
>              be provided.
>
>         I am sending the bearer token with the request and i make sure
>         in the
>         preflight its sent in the request.
>
>           1.
>              Access-Control-Request-Headers:
>              accept, authorization
>
>         Does anyone know if there Is something i'm missing ?  do i need
>         to get
>         authorization enabled or added anywhere ? as a side note i have
>         below in
>         my api as well:
>
>         response.setHeader("Access-Control-Allow-Headers", "Authorization");
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>


From fadiabdeen at gmail.com  Mon Aug 17 11:38:54 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 17 Aug 2015 11:38:54 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D1FFAD.3000201@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
Message-ID: <CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>

cool .. you're the man ;)


On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com> wrote:

> I'm actually testing the fix right now. It will land both on the 1.2.x
> branch and the 1.1.x branch shortly. You should be able to test it out
> in a short while: I'll send you an email when it's available.
>
> On 17/08/2015 16:23, Fadi Abdin wrote:
>
>> Thank you Marc,
>> Is there a work around that you can think of ?
>> I'm doing it with angularjs  , very simple
>>
>> $http({method: 'GET', url: 'http://server/apiman-gateway/service',
>> headers: {
>>      'Authorization': 'Bearer XXXXXXXXXXXXX'}
>> });
>>
>> I assume you will fix it in the new version , right?
>>
>>
>>
>> On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     This is related to the JIRA I linked you to
>>     (https://issues.jboss.org/browse/APIMAN-516). Because of the way the
>>     policy chain currently works the behaviour of CORS is invalid in a
>>     few very specific cases (e.g. when you stack it with an auth
>>     policy). I'll let you know when it's fixed.
>>
>>     Regards,
>>     Marc
>>
>>     On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>         I have a problem in calling a service in apiman-gateway with the
>>         Authorization: Bearer <token> in the header.
>>
>>         It seems to preflight OPTIONS and return
>>
>>           1.
>>              X-Policy-Failure-Message:
>>              OAuth2 'Authorization' header or 'access_token' query
>>         parameter must
>>              be provided.
>>
>>         I am sending the bearer token with the request and i make sure
>>         in the
>>         preflight its sent in the request.
>>
>>           1.
>>              Access-Control-Request-Headers:
>>              accept, authorization
>>
>>         Does anyone know if there Is something i'm missing ?  do i need
>>         to get
>>         authorization enabled or added anywhere ? as a side note i have
>>         below in
>>         my api as well:
>>
>>         response.setHeader("Access-Control-Allow-Headers",
>> "Authorization");
>>
>>
>>         _______________________________________________
>>         Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto: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/20150817/4530fd58/attachment-0001.html 

From eric.wittmann at redhat.com  Mon Aug 17 12:24:14 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 17 Aug 2015 12:24:14 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
Message-ID: <55D20AAE.6000002@redhat.com>

+1

On 8/17/2015 11:38 AM, Fadi Abdin wrote:
> cool .. you're the man ;)
>
>
> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I'm actually testing the fix right now. It will land both on the 1.2.x
>     branch and the 1.1.x branch shortly. You should be able to test it out
>     in a short while: I'll send you an email when it's available.
>
>     On 17/08/2015 16:23, Fadi Abdin wrote:
>
>         Thank you Marc,
>         Is there a work around that you can think of ?
>         I'm doing it with angularjs  , very simple
>
>         $http({method: 'GET', url: 'http://server/apiman-gateway/service',
>         headers: {
>               'Authorization': 'Bearer XXXXXXXXXXXXX'}
>         });
>
>         I assume you will fix it in the new version , right?
>
>
>
>         On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>> wrote:
>
>              Hi,
>
>              This is related to the JIRA I linked you to
>              (https://issues.jboss.org/browse/APIMAN-516). Because of
>         the way the
>              policy chain currently works the behaviour of CORS is
>         invalid in a
>              few very specific cases (e.g. when you stack it with an auth
>              policy). I'll let you know when it's fixed.
>
>              Regards,
>              Marc
>
>              On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                  I have a problem in calling a service in apiman-gateway
>         with the
>                  Authorization: Bearer <token> in the header.
>
>                  It seems to preflight OPTIONS and return
>
>                    1.
>                       X-Policy-Failure-Message:
>                       OAuth2 'Authorization' header or 'access_token' query
>                  parameter must
>                       be provided.
>
>                  I am sending the bearer token with the request and i
>         make sure
>                  in the
>                  preflight its sent in the request.
>
>                    1.
>                       Access-Control-Request-Headers:
>                       accept, authorization
>
>                  Does anyone know if there Is something i'm missing ?
>         do i need
>                  to get
>                  authorization enabled or added anywhere ? as a side
>         note i have
>                  below in
>                  my api as well:
>
>                  response.setHeader("Access-Control-Allow-Headers",
>         "Authorization");
>
>
>                  _______________________________________________
>                  Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Mon Aug 17 13:32:47 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 17 Aug 2015 18:32:47 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
Message-ID: <55D21ABF.6050901@redhat.com>

Hi Fadi,

Please feel free to try this out - you'll be building 1.1.7-SNAPSHOT
of apiman/apiman and apiman/apiman-plugins.

apiman:

git fetch origin pull/180/head:fix-cors
git checkout fix-cors
mvn clean install

apiman-plugins:

git fetch origin pull/26/head:fix-cors
git checkout fix-cors
mvn clean install

Make sure you build them in the order shown above and use 1.1.7-SNAPSHOT
of the CORS plugin.

This is using a snapshot from my PRs, so please don't forget about it
later, otherwise you'll be stuck on an old version!

Regards,
Marc

On 17/08/2015 16:38, Fadi Abdin wrote:
> cool .. you're the man ;)
>
>
> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I'm actually testing the fix right now. It will land both on the 1.2.x
>     branch and the 1.1.x branch shortly. You should be able to test it out
>     in a short while: I'll send you an email when it's available.
>
>     On 17/08/2015 16:23, Fadi Abdin wrote:
>
>         Thank you Marc,
>         Is there a work around that you can think of ?
>         I'm doing it with angularjs  , very simple
>
>         $http({method: 'GET', url: 'http://server/apiman-gateway/service',
>         headers: {
>               'Authorization': 'Bearer XXXXXXXXXXXXX'}
>         });
>
>         I assume you will fix it in the new version , right?
>
>
>
>         On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>> wrote:
>
>              Hi,
>
>              This is related to the JIRA I linked you to
>              (https://issues.jboss.org/browse/APIMAN-516). Because of
>         the way the
>              policy chain currently works the behaviour of CORS is
>         invalid in a
>              few very specific cases (e.g. when you stack it with an auth
>              policy). I'll let you know when it's fixed.
>
>              Regards,
>              Marc
>
>              On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                  I have a problem in calling a service in apiman-gateway
>         with the
>                  Authorization: Bearer <token> in the header.
>
>                  It seems to preflight OPTIONS and return
>
>                    1.
>                       X-Policy-Failure-Message:
>                       OAuth2 'Authorization' header or 'access_token' query
>                  parameter must
>                       be provided.
>
>                  I am sending the bearer token with the request and i
>         make sure
>                  in the
>                  preflight its sent in the request.
>
>                    1.
>                       Access-Control-Request-Headers:
>                       accept, authorization
>
>                  Does anyone know if there Is something i'm missing ?
>         do i need
>                  to get
>                  authorization enabled or added anywhere ? as a side
>         note i have
>                  below in
>                  my api as well:
>
>                  response.setHeader("Access-Control-Allow-Headers",
>         "Authorization");
>
>
>                  _______________________________________________
>                  Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>


From eric.wittmann at redhat.com  Mon Aug 17 14:02:43 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 17 Aug 2015 14:02:43 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D21ABF.6050901@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D21ABF.6050901@redhat.com>
Message-ID: <55D221C3.2010507@redhat.com>

Or if you can wait for 30 minutes you can do all this from 'master' or 
from the '1.1.x' branch.  :)

-Eric

On 8/17/2015 1:32 PM, Marc Savy wrote:
> Hi Fadi,
>
> Please feel free to try this out - you'll be building 1.1.7-SNAPSHOT
> of apiman/apiman and apiman/apiman-plugins.
>
> apiman:
>
> git fetch origin pull/180/head:fix-cors
> git checkout fix-cors
> mvn clean install
>
> apiman-plugins:
>
> git fetch origin pull/26/head:fix-cors
> git checkout fix-cors
> mvn clean install
>
> Make sure you build them in the order shown above and use 1.1.7-SNAPSHOT
> of the CORS plugin.
>
> This is using a snapshot from my PRs, so please don't forget about it
> later, otherwise you'll be stuck on an old version!
>
> Regards,
> Marc
>
> On 17/08/2015 16:38, Fadi Abdin wrote:
>> cool .. you're the man ;)
>>
>>
>> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>      I'm actually testing the fix right now. It will land both on the 1.2.x
>>      branch and the 1.1.x branch shortly. You should be able to test it out
>>      in a short while: I'll send you an email when it's available.
>>
>>      On 17/08/2015 16:23, Fadi Abdin wrote:
>>
>>          Thank you Marc,
>>          Is there a work around that you can think of ?
>>          I'm doing it with angularjs  , very simple
>>
>>          $http({method: 'GET', url: 'http://server/apiman-gateway/service',
>>          headers: {
>>                'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>          });
>>
>>          I assume you will fix it in the new version , right?
>>
>>
>>
>>          On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>> wrote:
>>
>>               Hi,
>>
>>               This is related to the JIRA I linked you to
>>               (https://issues.jboss.org/browse/APIMAN-516). Because of
>>          the way the
>>               policy chain currently works the behaviour of CORS is
>>          invalid in a
>>               few very specific cases (e.g. when you stack it with an auth
>>               policy). I'll let you know when it's fixed.
>>
>>               Regards,
>>               Marc
>>
>>               On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>                   I have a problem in calling a service in apiman-gateway
>>          with the
>>                   Authorization: Bearer <token> in the header.
>>
>>                   It seems to preflight OPTIONS and return
>>
>>                     1.
>>                        X-Policy-Failure-Message:
>>                        OAuth2 'Authorization' header or 'access_token' query
>>                   parameter must
>>                        be provided.
>>
>>                   I am sending the bearer token with the request and i
>>          make sure
>>                   in the
>>                   preflight its sent in the request.
>>
>>                     1.
>>                        Access-Control-Request-Headers:
>>                        accept, authorization
>>
>>                   Does anyone know if there Is something i'm missing ?
>>          do i need
>>                   to get
>>                   authorization enabled or added anywhere ? as a side
>>          note i have
>>                   below in
>>                   my api as well:
>>
>>                   response.setHeader("Access-Control-Allow-Headers",
>>          "Authorization");
>>
>>
>>                   _______________________________________________
>>                   Apiman-user mailing list
>>          Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>          <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>>
>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From fadiabdeen at gmail.com  Mon Aug 17 14:11:18 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Mon, 17 Aug 2015 14:11:18 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D221C3.2010507@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D21ABF.6050901@redhat.com> <55D221C3.2010507@redhat.com>
Message-ID: <CABXXV0QH84f9hs544popCYK4nT4WOTR=uegNV=xVR+WgQ0O0Xg@mail.gmail.com>

yeah i can wait.

The way i run apiman is by downloading wildfly and the apiman-overlay zip
files and then unzip and run ..

Do you have instructions somewhere to update with a new version by building
the code ? i can mvn install and drop the files , but i dont think this is
enough , is it ?

On Mon, Aug 17, 2015 at 2:02 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Or if you can wait for 30 minutes you can do all this from 'master' or
> from the '1.1.x' branch.  :)
>
> -Eric
>
>
> On 8/17/2015 1:32 PM, Marc Savy wrote:
>
>> Hi Fadi,
>>
>> Please feel free to try this out - you'll be building 1.1.7-SNAPSHOT
>> of apiman/apiman and apiman/apiman-plugins.
>>
>> apiman:
>>
>> git fetch origin pull/180/head:fix-cors
>> git checkout fix-cors
>> mvn clean install
>>
>> apiman-plugins:
>>
>> git fetch origin pull/26/head:fix-cors
>> git checkout fix-cors
>> mvn clean install
>>
>> Make sure you build them in the order shown above and use 1.1.7-SNAPSHOT
>> of the CORS plugin.
>>
>> This is using a snapshot from my PRs, so please don't forget about it
>> later, otherwise you'll be stuck on an old version!
>>
>> Regards,
>> Marc
>>
>> On 17/08/2015 16:38, Fadi Abdin wrote:
>>
>>> cool .. you're the man ;)
>>>
>>>
>>> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
>>> <mailto:marc.savy at redhat.com>> wrote:
>>>
>>>      I'm actually testing the fix right now. It will land both on the
>>> 1.2.x
>>>      branch and the 1.1.x branch shortly. You should be able to test it
>>> out
>>>      in a short while: I'll send you an email when it's available.
>>>
>>>      On 17/08/2015 16:23, Fadi Abdin wrote:
>>>
>>>          Thank you Marc,
>>>          Is there a work around that you can think of ?
>>>          I'm doing it with angularjs  , very simple
>>>
>>>          $http({method: 'GET', url: '
>>> http://server/apiman-gateway/service',
>>>          headers: {
>>>                'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>>          });
>>>
>>>          I assume you will fix it in the new version , right?
>>>
>>>
>>>
>>>          On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>>> wrote:
>>>
>>>               Hi,
>>>
>>>               This is related to the JIRA I linked you to
>>>               (https://issues.jboss.org/browse/APIMAN-516). Because of
>>>          the way the
>>>               policy chain currently works the behaviour of CORS is
>>>          invalid in a
>>>               few very specific cases (e.g. when you stack it with an
>>> auth
>>>               policy). I'll let you know when it's fixed.
>>>
>>>               Regards,
>>>               Marc
>>>
>>>               On 17/08/2015 15:44, Fadi Abdin wrote:
>>>
>>>                   I have a problem in calling a service in apiman-gateway
>>>          with the
>>>                   Authorization: Bearer <token> in the header.
>>>
>>>                   It seems to preflight OPTIONS and return
>>>
>>>                     1.
>>>                        X-Policy-Failure-Message:
>>>                        OAuth2 'Authorization' header or 'access_token'
>>> query
>>>                   parameter must
>>>                        be provided.
>>>
>>>                   I am sending the bearer token with the request and i
>>>          make sure
>>>                   in the
>>>                   preflight its sent in the request.
>>>
>>>                     1.
>>>                        Access-Control-Request-Headers:
>>>                        accept, authorization
>>>
>>>                   Does anyone know if there Is something i'm missing ?
>>>          do i need
>>>                   to get
>>>                   authorization enabled or added anywhere ? as a side
>>>          note i have
>>>                   below in
>>>                   my api as well:
>>>
>>>                   response.setHeader("Access-Control-Allow-Headers",
>>>          "Authorization");
>>>
>>>
>>>                   _______________________________________________
>>>                   Apiman-user mailing list
>>>          Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org
>>> >
>>>          <mailto:Apiman-user at lists.jboss.org
>>>          <mailto:Apiman-user at lists.jboss.org>>
>>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 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/20150817/36f6e67f/attachment-0001.html 

From eric.wittmann at redhat.com  Mon Aug 17 14:47:34 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 17 Aug 2015 14:47:34 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0QH84f9hs544popCYK4nT4WOTR=uegNV=xVR+WgQ0O0Xg@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D21ABF.6050901@redhat.com> <55D221C3.2010507@redhat.com>
	<CABXXV0QH84f9hs544popCYK4nT4WOTR=uegNV=xVR+WgQ0O0Xg@mail.gmail.com>
Message-ID: <55D22C46.8060208@redhat.com>

If you build apiman from source using maven, the same ZIP file you've 
been using via the download mechanism will be created.  For example:

git clone git at github.com:apiman/apiman.git
cd apiman
git checkout 1.1.x
mvn clean install -DskipTests
ls -al 
distro/wildfly8/target/apiman-distro-wildfly8-1.2.0-SNAPSHOT-overlay.zip

That file should now exist - you can copy it off somewhere and use it 
just like the one you normally download.

For the plugin, you simply need to check out the code and build it. 
Then you can add the plugin via the UI as normal.  Example:

git clone git at github.com:apiman/apiman-plugins.git
cd apiman-plugins
mvn clean install

Then use the UI to install it.

-Eric

On 8/17/2015 2:11 PM, Fadi Abdin wrote:
> yeah i can wait.
>
> The way i run apiman is by downloading wildfly and the apiman-overlay
> zip files and then unzip and run ..
>
> Do you have instructions somewhere to update with a new version by
> building the code ? i can mvn install and drop the files , but i dont
> think this is enough , is it ?
>
> On Mon, Aug 17, 2015 at 2:02 PM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Or if you can wait for 30 minutes you can do all this from 'master'
>     or from the '1.1.x' branch.  :)
>
>     -Eric
>
>
>     On 8/17/2015 1:32 PM, Marc Savy wrote:
>
>         Hi Fadi,
>
>         Please feel free to try this out - you'll be building 1.1.7-SNAPSHOT
>         of apiman/apiman and apiman/apiman-plugins.
>
>         apiman:
>
>         git fetch origin pull/180/head:fix-cors
>         git checkout fix-cors
>         mvn clean install
>
>         apiman-plugins:
>
>         git fetch origin pull/26/head:fix-cors
>         git checkout fix-cors
>         mvn clean install
>
>         Make sure you build them in the order shown above and use
>         1.1.7-SNAPSHOT
>         of the CORS plugin.
>
>         This is using a snapshot from my PRs, so please don't forget
>         about it
>         later, otherwise you'll be stuck on an old version!
>
>         Regards,
>         Marc
>
>         On 17/08/2015 16:38, Fadi Abdin wrote:
>
>             cool .. you're the man ;)
>
>
>             On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>             wrote:
>
>                   I'm actually testing the fix right now. It will land
>             both on the 1.2.x
>                   branch and the 1.1.x branch shortly. You should be
>             able to test it out
>                   in a short while: I'll send you an email when it's
>             available.
>
>                   On 17/08/2015 16:23, Fadi Abdin wrote:
>
>                       Thank you Marc,
>                       Is there a work around that you can think of ?
>                       I'm doing it with angularjs  , very simple
>
>                       $http({method: 'GET', url:
>             'http://server/apiman-gateway/service',
>                       headers: {
>                             'Authorization': 'Bearer XXXXXXXXXXXXX'}
>                       });
>
>                       I assume you will fix it in the new version , right?
>
>
>
>                       On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>                       <marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>
>                       <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>> wrote:
>
>                            Hi,
>
>                            This is related to the JIRA I linked you to
>                            (https://issues.jboss.org/browse/APIMAN-516).
>             Because of
>                       the way the
>                            policy chain currently works the behaviour of
>             CORS is
>                       invalid in a
>                            few very specific cases (e.g. when you stack
>             it with an auth
>                            policy). I'll let you know when it's fixed.
>
>                            Regards,
>                            Marc
>
>                            On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                                I have a problem in calling a service in
>             apiman-gateway
>                       with the
>                                Authorization: Bearer <token> in the header.
>
>                                It seems to preflight OPTIONS and return
>
>                                  1.
>                                     X-Policy-Failure-Message:
>                                     OAuth2 'Authorization' header or
>             'access_token' query
>                                parameter must
>                                     be provided.
>
>                                I am sending the bearer token with the
>             request and i
>                       make sure
>                                in the
>                                preflight its sent in the request.
>
>                                  1.
>                                     Access-Control-Request-Headers:
>                                     accept, authorization
>
>                                Does anyone know if there Is something
>             i'm missing ?
>                       do i need
>                                to get
>                                authorization enabled or added anywhere ?
>             as a side
>                       note i have
>                                below in
>                                my api as well:
>
>
>             response.setHeader("Access-Control-Allow-Headers",
>                       "Authorization");
>
>
>
>             _______________________________________________
>                                Apiman-user mailing list
>             Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                       <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                       <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>

From eric.wittmann at redhat.com  Mon Aug 17 14:56:47 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 17 Aug 2015 14:56:47 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D22C46.8060208@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D21ABF.6050901@redhat.com> <55D221C3.2010507@redhat.com>
	<CABXXV0QH84f9hs544popCYK4nT4WOTR=uegNV=xVR+WgQ0O0Xg@mail.gmail.com>
	<55D22C46.8060208@redhat.com>
Message-ID: <55D22E6F.1080901@redhat.com>

Correction on my instructions below.  Thanks to msavy for pointing this out:

git clone git at github.com:apiman/apiman.git
cd apiman
git checkout 1.1.x
mvn clean install -DskipTests
ls -al
distro/wildfly8/target/apiman-distro-wildfly8-1.1.7-SNAPSHOT-overlay.zip

Also don't forget to use 1.1.7-SNAPSHOT when you install the CORS plugin.

-Eric

On 8/17/2015 2:47 PM, Eric Wittmann wrote:
> If you build apiman from source using maven, the same ZIP file you've
> been using via the download mechanism will be created.  For example:
>
> git clone git at github.com:apiman/apiman.git
> cd apiman
> git checkout 1.1.x
> mvn clean install -DskipTests
> ls -al
> distro/wildfly8/target/apiman-distro-wildfly8-1.2.0-SNAPSHOT-overlay.zip
>
> That file should now exist - you can copy it off somewhere and use it
> just like the one you normally download.
>
> For the plugin, you simply need to check out the code and build it. Then
> you can add the plugin via the UI as normal.  Example:
>
> git clone git at github.com:apiman/apiman-plugins.git
> cd apiman-plugins
> mvn clean install
>
> Then use the UI to install it.
>
> -Eric
>
> On 8/17/2015 2:11 PM, Fadi Abdin wrote:
>> yeah i can wait.
>>
>> The way i run apiman is by downloading wildfly and the apiman-overlay
>> zip files and then unzip and run ..
>>
>> Do you have instructions somewhere to update with a new version by
>> building the code ? i can mvn install and drop the files , but i dont
>> think this is enough , is it ?
>>
>> On Mon, Aug 17, 2015 at 2:02 PM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>     Or if you can wait for 30 minutes you can do all this from 'master'
>>     or from the '1.1.x' branch.  :)
>>
>>     -Eric
>>
>>
>>     On 8/17/2015 1:32 PM, Marc Savy wrote:
>>
>>         Hi Fadi,
>>
>>         Please feel free to try this out - you'll be building
>> 1.1.7-SNAPSHOT
>>         of apiman/apiman and apiman/apiman-plugins.
>>
>>         apiman:
>>
>>         git fetch origin pull/180/head:fix-cors
>>         git checkout fix-cors
>>         mvn clean install
>>
>>         apiman-plugins:
>>
>>         git fetch origin pull/26/head:fix-cors
>>         git checkout fix-cors
>>         mvn clean install
>>
>>         Make sure you build them in the order shown above and use
>>         1.1.7-SNAPSHOT
>>         of the CORS plugin.
>>
>>         This is using a snapshot from my PRs, so please don't forget
>>         about it
>>         later, otherwise you'll be stuck on an old version!
>>
>>         Regards,
>>         Marc
>>
>>         On 17/08/2015 16:38, Fadi Abdin wrote:
>>
>>             cool .. you're the man ;)
>>
>>
>>             On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>>             wrote:
>>
>>                   I'm actually testing the fix right now. It will land
>>             both on the 1.2.x
>>                   branch and the 1.1.x branch shortly. You should be
>>             able to test it out
>>                   in a short while: I'll send you an email when it's
>>             available.
>>
>>                   On 17/08/2015 16:23, Fadi Abdin wrote:
>>
>>                       Thank you Marc,
>>                       Is there a work around that you can think of ?
>>                       I'm doing it with angularjs  , very simple
>>
>>                       $http({method: 'GET', url:
>>             'http://server/apiman-gateway/service',
>>                       headers: {
>>                             'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>                       });
>>
>>                       I assume you will fix it in the new version ,
>> right?
>>
>>
>>
>>                       On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>                       <marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com>>
>>                       <mailto:marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com>>>> wrote:
>>
>>                            Hi,
>>
>>                            This is related to the JIRA I linked you to
>>                            (https://issues.jboss.org/browse/APIMAN-516).
>>             Because of
>>                       the way the
>>                            policy chain currently works the behaviour of
>>             CORS is
>>                       invalid in a
>>                            few very specific cases (e.g. when you stack
>>             it with an auth
>>                            policy). I'll let you know when it's fixed.
>>
>>                            Regards,
>>                            Marc
>>
>>                            On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>                                I have a problem in calling a service in
>>             apiman-gateway
>>                       with the
>>                                Authorization: Bearer <token> in the
>> header.
>>
>>                                It seems to preflight OPTIONS and return
>>
>>                                  1.
>>                                     X-Policy-Failure-Message:
>>                                     OAuth2 'Authorization' header or
>>             'access_token' query
>>                                parameter must
>>                                     be provided.
>>
>>                                I am sending the bearer token with the
>>             request and i
>>                       make sure
>>                                in the
>>                                preflight its sent in the request.
>>
>>                                  1.
>>                                     Access-Control-Request-Headers:
>>                                     accept, authorization
>>
>>                                Does anyone know if there Is something
>>             i'm missing ?
>>                       do i need
>>                                to get
>>                                authorization enabled or added anywhere ?
>>             as a side
>>                       note i have
>>                                below in
>>                                my api as well:
>>
>>
>>             response.setHeader("Access-Control-Allow-Headers",
>>                       "Authorization");
>>
>>
>>
>>             _______________________________________________
>>                                Apiman-user mailing list
>>             Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>
>>             <mailto:Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>>
>>                       <mailto:Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>
>>                       <mailto:Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>>>
>>             https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>

From fadiabdeen at gmail.com  Tue Aug 18 08:13:45 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Tue, 18 Aug 2015 08:13:45 -0400
Subject: [Apiman-user] Upgrade APIMan version
Message-ID: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>

Hello,

Is there a way to update apiman version without losing keycloak and apiman
configuration ?

I follow the instructions on http://www.apiman.io/latest/download.html to
install apiman , currently i'm on 1.1.3.  I have keycloak setup with my
custom realm which include LDAP connections and clients setup with their
own secrets. For APIMan , i have my custom organization , services and
keycloak plugin.

I would like to upgrade without losing all this setup .

Thanks,
Fadi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150818/b6857fb4/attachment.html 

From eric.wittmann at redhat.com  Tue Aug 18 08:27:15 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 18 Aug 2015 08:27:15 -0400
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
Message-ID: <55D324A3.3020008@redhat.com>

As it is still early days for apiman, we haven't worked out a robust 
upgrade process yet.  It's something that is on the roadmap.

The good news is that for keycloak the upgrade should be easy - just 
copy your database over from the old install to the new one.

Sadly that won't work for apiman, as the database schema has changed. 
I'm sorry to say that your best bet is probably to install apiman fresh 
and then re-create your config either using the UI or the REST 
interface.  In the future we plan on having an Export feature that will 
export all the apiman config to a file for import into a different 
server.  Such a feature will help a lot for upgrades.

-Eric

On 8/18/2015 8:13 AM, Fadi Abdin wrote:
> Hello,
>
> Is there a way to update apiman version without losing keycloak and
> apiman configuration ?
>
> I follow the instructions on http://www.apiman.io/latest/download.html
> to install apiman , currently i'm on 1.1.3.  I have keycloak setup with
> my custom realm which include LDAP connections and clients setup with
> their own secrets. For APIMan , i have my custom organization , services
> and keycloak plugin.
>
> I would like to upgrade without losing all this setup .
>
> Thanks,
> Fadi
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From fadiabdeen at gmail.com  Tue Aug 18 08:32:21 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Tue, 18 Aug 2015 08:32:21 -0400
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <55D324A3.3020008@redhat.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
	<55D324A3.3020008@redhat.com>
Message-ID: <CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>

I am watching that ticket for export / import , hopefully will come soon .

For keycloak , is it just the keycloak.h2.db ?

On Tue, Aug 18, 2015 at 8:27 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> As it is still early days for apiman, we haven't worked out a robust
> upgrade process yet.  It's something that is on the roadmap.
>
> The good news is that for keycloak the upgrade should be easy - just copy
> your database over from the old install to the new one.
>
> Sadly that won't work for apiman, as the database schema has changed. I'm
> sorry to say that your best bet is probably to install apiman fresh and
> then re-create your config either using the UI or the REST interface.  In
> the future we plan on having an Export feature that will export all the
> apiman config to a file for import into a different server.  Such a feature
> will help a lot for upgrades.
>
> -Eric
>
>
> On 8/18/2015 8:13 AM, Fadi Abdin wrote:
>
>> Hello,
>>
>> Is there a way to update apiman version without losing keycloak and
>> apiman configuration ?
>>
>> I follow the instructions on http://www.apiman.io/latest/download.html
>> to install apiman , currently i'm on 1.1.3.  I have keycloak setup with
>> my custom realm which include LDAP connections and clients setup with
>> their own secrets. For APIMan , i have my custom organization , services
>> and keycloak plugin.
>>
>> I would like to upgrade without losing all this setup .
>>
>> Thanks,
>> Fadi
>>
>>
>> _______________________________________________
>> 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/20150818/926b406a/attachment-0001.html 

From marc.savy at redhat.com  Tue Aug 18 08:43:27 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 18 Aug 2015 13:43:27 +0100
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
	<55D324A3.3020008@redhat.com>
	<CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
Message-ID: <55D3286F.7010500@redhat.com>

Check the keycloak docs -

https://keycloak.github.io/docs/userguide/html/export-import.html
https://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html

On 18/08/2015 13:32, Fadi Abdin wrote:
> I am watching that ticket for export / import , hopefully will come soon .
>
> For keycloak , is it just the keycloak.h2.db ?
>
> On Tue, Aug 18, 2015 at 8:27 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     As it is still early days for apiman, we haven't worked out a robust
>     upgrade process yet.  It's something that is on the roadmap.
>
>     The good news is that for keycloak the upgrade should be easy - just
>     copy your database over from the old install to the new one.
>
>     Sadly that won't work for apiman, as the database schema has
>     changed. I'm sorry to say that your best bet is probably to install
>     apiman fresh and then re-create your config either using the UI or
>     the REST interface.  In the future we plan on having an Export
>     feature that will export all the apiman config to a file for import
>     into a different server.  Such a feature will help a lot for upgrades.
>
>     -Eric
>
>
>     On 8/18/2015 8:13 AM, Fadi Abdin wrote:
>
>         Hello,
>
>         Is there a way to update apiman version without losing keycloak and
>         apiman configuration ?
>
>         I follow the instructions on
>         http://www.apiman.io/latest/download.html
>         to install apiman , currently i'm on 1.1.3.  I have keycloak
>         setup with
>         my custom realm which include LDAP connections and clients setup
>         with
>         their own secrets. For APIMan , i have my custom organization ,
>         services
>         and keycloak plugin.
>
>         I would like to upgrade without losing all this setup .
>
>         Thanks,
>         Fadi
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Tue Aug 18 08:50:06 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 18 Aug 2015 08:50:06 -0400
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
	<55D324A3.3020008@redhat.com>
	<CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
Message-ID: <55D329FE.7020505@redhat.com>

Yes, that keycloak.h2.db file *should* be all you need.  But obviously 
I'd recommend testing the heck out of that. :)

-Eric

On 8/18/2015 8:32 AM, Fadi Abdin wrote:
> I am watching that ticket for export / import , hopefully will come soon .
>
> For keycloak , is it just the keycloak.h2.db ?
>
> On Tue, Aug 18, 2015 at 8:27 AM, Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
>
>     As it is still early days for apiman, we haven't worked out a robust
>     upgrade process yet.  It's something that is on the roadmap.
>
>     The good news is that for keycloak the upgrade should be easy - just
>     copy your database over from the old install to the new one.
>
>     Sadly that won't work for apiman, as the database schema has
>     changed. I'm sorry to say that your best bet is probably to install
>     apiman fresh and then re-create your config either using the UI or
>     the REST interface.  In the future we plan on having an Export
>     feature that will export all the apiman config to a file for import
>     into a different server.  Such a feature will help a lot for upgrades.
>
>     -Eric
>
>
>     On 8/18/2015 8:13 AM, Fadi Abdin wrote:
>
>         Hello,
>
>         Is there a way to update apiman version without losing keycloak and
>         apiman configuration ?
>
>         I follow the instructions on
>         http://www.apiman.io/latest/download.html
>         to install apiman , currently i'm on 1.1.3.  I have keycloak
>         setup with
>         my custom realm which include LDAP connections and clients setup
>         with
>         their own secrets. For APIMan , i have my custom organization ,
>         services
>         and keycloak plugin.
>
>         I would like to upgrade without losing all this setup .
>
>         Thanks,
>         Fadi
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>

From eric.wittmann at redhat.com  Tue Aug 18 08:50:59 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 18 Aug 2015 08:50:59 -0400
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <55D3286F.7010500@redhat.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
	<55D324A3.3020008@redhat.com>
	<CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
	<55D3286F.7010500@redhat.com>
Message-ID: <55D32A33.4040707@redhat.com>

Ah great - thanks Marc!

On 8/18/2015 8:43 AM, Marc Savy wrote:
> Check the keycloak docs -
>
> https://keycloak.github.io/docs/userguide/html/export-import.html
> https://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html
>
> On 18/08/2015 13:32, Fadi Abdin wrote:
>> I am watching that ticket for export / import , hopefully will come soon .
>>
>> For keycloak , is it just the keycloak.h2.db ?
>>
>> On Tue, Aug 18, 2015 at 8:27 AM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>      As it is still early days for apiman, we haven't worked out a robust
>>      upgrade process yet.  It's something that is on the roadmap.
>>
>>      The good news is that for keycloak the upgrade should be easy - just
>>      copy your database over from the old install to the new one.
>>
>>      Sadly that won't work for apiman, as the database schema has
>>      changed. I'm sorry to say that your best bet is probably to install
>>      apiman fresh and then re-create your config either using the UI or
>>      the REST interface.  In the future we plan on having an Export
>>      feature that will export all the apiman config to a file for import
>>      into a different server.  Such a feature will help a lot for upgrades.
>>
>>      -Eric
>>
>>
>>      On 8/18/2015 8:13 AM, Fadi Abdin wrote:
>>
>>          Hello,
>>
>>          Is there a way to update apiman version without losing keycloak and
>>          apiman configuration ?
>>
>>          I follow the instructions on
>>          http://www.apiman.io/latest/download.html
>>          to install apiman , currently i'm on 1.1.3.  I have keycloak
>>          setup with
>>          my custom realm which include LDAP connections and clients setup
>>          with
>>          their own secrets. For APIMan , i have my custom organization ,
>>          services
>>          and keycloak plugin.
>>
>>          I would like to upgrade without losing all this setup .
>>
>>          Thanks,
>>          Fadi
>>
>>
>>          _______________________________________________
>>          Apiman-user mailing list
>>          Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From fadiabdeen at gmail.com  Tue Aug 18 09:20:43 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Tue, 18 Aug 2015 09:20:43 -0400
Subject: [Apiman-user] Upgrade APIMan version
In-Reply-To: <55D32A33.4040707@redhat.com>
References: <CABXXV0RvMgtNtOEqj+r01esnc215fwY6AsJP9aVy2mb7oEn_tA@mail.gmail.com>
	<55D324A3.3020008@redhat.com>
	<CABXXV0Rg1HQAuy=BWkj9u6pjhswhp8Nw+27OG768fGOmABkOKQ@mail.gmail.com>
	<55D3286F.7010500@redhat.com> <55D32A33.4040707@redhat.com>
Message-ID: <CABXXV0TRTV_VXn-gq6_99qgg8jSU+Q5tPznJY=7CcEWu7-Kq7g@mail.gmail.com>

Great , thank you guys :)

On Tue, Aug 18, 2015 at 8:50 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Ah great - thanks Marc!
>
> On 8/18/2015 8:43 AM, Marc Savy wrote:
> > Check the keycloak docs -
> >
> > https://keycloak.github.io/docs/userguide/html/export-import.html
> >
> https://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html
> >
> > On 18/08/2015 13:32, Fadi Abdin wrote:
> >> I am watching that ticket for export / import , hopefully will come
> soon .
> >>
> >> For keycloak , is it just the keycloak.h2.db ?
> >>
> >> On Tue, Aug 18, 2015 at 8:27 AM, Eric Wittmann <
> eric.wittmann at redhat.com
> >> <mailto:eric.wittmann at redhat.com>> wrote:
> >>
> >>      As it is still early days for apiman, we haven't worked out a
> robust
> >>      upgrade process yet.  It's something that is on the roadmap.
> >>
> >>      The good news is that for keycloak the upgrade should be easy -
> just
> >>      copy your database over from the old install to the new one.
> >>
> >>      Sadly that won't work for apiman, as the database schema has
> >>      changed. I'm sorry to say that your best bet is probably to install
> >>      apiman fresh and then re-create your config either using the UI or
> >>      the REST interface.  In the future we plan on having an Export
> >>      feature that will export all the apiman config to a file for import
> >>      into a different server.  Such a feature will help a lot for
> upgrades.
> >>
> >>      -Eric
> >>
> >>
> >>      On 8/18/2015 8:13 AM, Fadi Abdin wrote:
> >>
> >>          Hello,
> >>
> >>          Is there a way to update apiman version without losing
> keycloak and
> >>          apiman configuration ?
> >>
> >>          I follow the instructions on
> >>          http://www.apiman.io/latest/download.html
> >>          to install apiman , currently i'm on 1.1.3.  I have keycloak
> >>          setup with
> >>          my custom realm which include LDAP connections and clients
> setup
> >>          with
> >>          their own secrets. For APIMan , i have my custom organization ,
> >>          services
> >>          and keycloak plugin.
> >>
> >>          I would like to upgrade without losing all this setup .
> >>
> >>          Thanks,
> >>          Fadi
> >>
> >>
> >>          _______________________________________________
> >>          Apiman-user mailing list
> >>          Apiman-user at lists.jboss.org <mailto:
> Apiman-user at lists.jboss.org>
> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
> _______________________________________________
> 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/20150818/df41fdab/attachment.html 

From marc.savy at redhat.com  Tue Aug 18 09:46:56 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 18 Aug 2015 14:46:56 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
Message-ID: <55D33750.6020701@redhat.com>

My pleasure! Did it work?

On 17/08/2015 16:38, Fadi Abdin wrote:
> cool .. you're the man ;)
>
>
> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I'm actually testing the fix right now. It will land both on the 1.2.x
>     branch and the 1.1.x branch shortly. You should be able to test it out
>     in a short while: I'll send you an email when it's available.
>
>     On 17/08/2015 16:23, Fadi Abdin wrote:
>
>         Thank you Marc,
>         Is there a work around that you can think of ?
>         I'm doing it with angularjs  , very simple
>
>         $http({method: 'GET', url: 'http://server/apiman-gateway/service',
>         headers: {
>               'Authorization': 'Bearer XXXXXXXXXXXXX'}
>         });
>
>         I assume you will fix it in the new version , right?
>
>
>
>         On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>> wrote:
>
>              Hi,
>
>              This is related to the JIRA I linked you to
>              (https://issues.jboss.org/browse/APIMAN-516). Because of
>         the way the
>              policy chain currently works the behaviour of CORS is
>         invalid in a
>              few very specific cases (e.g. when you stack it with an auth
>              policy). I'll let you know when it's fixed.
>
>              Regards,
>              Marc
>
>              On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                  I have a problem in calling a service in apiman-gateway
>         with the
>                  Authorization: Bearer <token> in the header.
>
>                  It seems to preflight OPTIONS and return
>
>                    1.
>                       X-Policy-Failure-Message:
>                       OAuth2 'Authorization' header or 'access_token' query
>                  parameter must
>                       be provided.
>
>                  I am sending the bearer token with the request and i
>         make sure
>                  in the
>                  preflight its sent in the request.
>
>                    1.
>                       Access-Control-Request-Headers:
>                       accept, authorization
>
>                  Does anyone know if there Is something i'm missing ?
>         do i need
>                  to get
>                  authorization enabled or added anywhere ? as a side
>         note i have
>                  below in
>                  my api as well:
>
>                  response.setHeader("Access-Control-Allow-Headers",
>         "Authorization");
>
>
>                  _______________________________________________
>                  Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>


From fadiabdeen at gmail.com  Tue Aug 18 10:48:17 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Tue, 18 Aug 2015 10:48:17 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D33750.6020701@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
Message-ID: <CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>

I'm still working on it :( .. i had to give the network guys few ip
addresses to whitelist so i can mvn install .. ... almost there.

On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy <marc.savy at redhat.com> wrote:

> My pleasure! Did it work?
>
> On 17/08/2015 16:38, Fadi Abdin wrote:
>
>> cool .. you're the man ;)
>>
>>
>> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>     I'm actually testing the fix right now. It will land both on the 1.2.x
>>     branch and the 1.1.x branch shortly. You should be able to test it out
>>     in a short while: I'll send you an email when it's available.
>>
>>     On 17/08/2015 16:23, Fadi Abdin wrote:
>>
>>         Thank you Marc,
>>         Is there a work around that you can think of ?
>>         I'm doing it with angularjs  , very simple
>>
>>         $http({method: 'GET', url: 'http://server/apiman-gateway/service
>> ',
>>         headers: {
>>               'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>         });
>>
>>         I assume you will fix it in the new version , right?
>>
>>
>>
>>         On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>> wrote:
>>
>>              Hi,
>>
>>              This is related to the JIRA I linked you to
>>              (https://issues.jboss.org/browse/APIMAN-516). Because of
>>         the way the
>>              policy chain currently works the behaviour of CORS is
>>         invalid in a
>>              few very specific cases (e.g. when you stack it with an auth
>>              policy). I'll let you know when it's fixed.
>>
>>              Regards,
>>              Marc
>>
>>              On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>                  I have a problem in calling a service in apiman-gateway
>>         with the
>>                  Authorization: Bearer <token> in the header.
>>
>>                  It seems to preflight OPTIONS and return
>>
>>                    1.
>>                       X-Policy-Failure-Message:
>>                       OAuth2 'Authorization' header or 'access_token'
>> query
>>                  parameter must
>>                       be provided.
>>
>>                  I am sending the bearer token with the request and i
>>         make sure
>>                  in the
>>                  preflight its sent in the request.
>>
>>                    1.
>>                       Access-Control-Request-Headers:
>>                       accept, authorization
>>
>>                  Does anyone know if there Is something i'm missing ?
>>         do i need
>>                  to get
>>                  authorization enabled or added anywhere ? as a side
>>         note i have
>>                  below in
>>                  my api as well:
>>
>>                  response.setHeader("Access-Control-Allow-Headers",
>>         "Authorization");
>>
>>
>>                  _______________________________________________
>>                  Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         <mailto:Apiman-user at lists.jboss.org
>>         <mailto: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/20150818/0aafd30d/attachment-0001.html 

From fadiabdeen at gmail.com  Tue Aug 18 14:25:26 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Tue, 18 Aug 2015 14:25:26 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
Message-ID: <CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>

It did not work .

I setup everything they way you told me Marc and i'm testing it on my
local.
It seems its sending that preflight OPTIONS and coming back with 401 still

On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin <fadiabdeen at gmail.com> wrote:

> I'm still working on it :( .. i had to give the network guys few ip
> addresses to whitelist so i can mvn install .. ... almost there.
>
> On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> My pleasure! Did it work?
>>
>> On 17/08/2015 16:38, Fadi Abdin wrote:
>>
>>> cool .. you're the man ;)
>>>
>>>
>>> On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy <marc.savy at redhat.com
>>> <mailto:marc.savy at redhat.com>> wrote:
>>>
>>>     I'm actually testing the fix right now. It will land both on the
>>> 1.2.x
>>>     branch and the 1.1.x branch shortly. You should be able to test it
>>> out
>>>     in a short while: I'll send you an email when it's available.
>>>
>>>     On 17/08/2015 16:23, Fadi Abdin wrote:
>>>
>>>         Thank you Marc,
>>>         Is there a work around that you can think of ?
>>>         I'm doing it with angularjs  , very simple
>>>
>>>         $http({method: 'GET', url: 'http://server/apiman-gateway/service
>>> ',
>>>         headers: {
>>>               'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>>         });
>>>
>>>         I assume you will fix it in the new version , right?
>>>
>>>
>>>
>>>         On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>>> wrote:
>>>
>>>              Hi,
>>>
>>>              This is related to the JIRA I linked you to
>>>              (https://issues.jboss.org/browse/APIMAN-516). Because of
>>>         the way the
>>>              policy chain currently works the behaviour of CORS is
>>>         invalid in a
>>>              few very specific cases (e.g. when you stack it with an auth
>>>              policy). I'll let you know when it's fixed.
>>>
>>>              Regards,
>>>              Marc
>>>
>>>              On 17/08/2015 15:44, Fadi Abdin wrote:
>>>
>>>                  I have a problem in calling a service in apiman-gateway
>>>         with the
>>>                  Authorization: Bearer <token> in the header.
>>>
>>>                  It seems to preflight OPTIONS and return
>>>
>>>                    1.
>>>                       X-Policy-Failure-Message:
>>>                       OAuth2 'Authorization' header or 'access_token'
>>> query
>>>                  parameter must
>>>                       be provided.
>>>
>>>                  I am sending the bearer token with the request and i
>>>         make sure
>>>                  in the
>>>                  preflight its sent in the request.
>>>
>>>                    1.
>>>                       Access-Control-Request-Headers:
>>>                       accept, authorization
>>>
>>>                  Does anyone know if there Is something i'm missing ?
>>>         do i need
>>>                  to get
>>>                  authorization enabled or added anywhere ? as a side
>>>         note i have
>>>                  below in
>>>                  my api as well:
>>>
>>>                  response.setHeader("Access-Control-Allow-Headers",
>>>         "Authorization");
>>>
>>>
>>>                  _______________________________________________
>>>                  Apiman-user mailing list
>>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>>         <mailto:Apiman-user at lists.jboss.org
>>>         <mailto: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/20150818/af6b3658/attachment.html 

From marc.savy at redhat.com  Wed Aug 19 05:53:05 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 10:53:05 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
Message-ID: <55D45201.9060907@redhat.com>

I replicated your set up as far as I could, and I couldn't replicate your issue (perhaps your CORS setup is wrong?). Please see the JIRA comments and screenshots - https://issues.jboss.org/browse/APIMAN-516

Either way, I also fixed a bug unrelated to your problem, so please re-build the plugins before trying again :-).

On 18/08/2015 19:25, Fadi Abdin wrote:
> It did not work .
>
> I setup everything they way you told me Marc and i'm testing it on my
> local.
> It seems its sending that preflight OPTIONS and coming back with 401 still
>
> On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin <fadiabdeen at gmail.com
> <mailto:fadiabdeen at gmail.com>> wrote:
>
>     I'm still working on it :( .. i had to give the network guys few ip
>     addresses to whitelist so i can mvn install .. ... almost there.
>
>     On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy <marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>> wrote:
>
>         My pleasure! Did it work?
>
>         On 17/08/2015 16:38, Fadi Abdin wrote:
>
>             cool .. you're the man ;)
>
>
>             On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>             wrote:
>
>                  I'm actually testing the fix right now. It will land
>             both on the 1.2.x
>                  branch and the 1.1.x branch shortly. You should be able
>             to test it out
>                  in a short while: I'll send you an email when it's
>             available.
>
>                  On 17/08/2015 16:23, Fadi Abdin wrote:
>
>                      Thank you Marc,
>                      Is there a work around that you can think of ?
>                      I'm doing it with angularjs  , very simple
>
>                      $http({method: 'GET', url:
>             'http://server/apiman-gateway/service',
>                      headers: {
>                            'Authorization': 'Bearer XXXXXXXXXXXXX'}
>                      });
>
>                      I assume you will fix it in the new version , right?
>
>
>
>                      On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>                      <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                      <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>> wrote:
>
>                           Hi,
>
>                           This is related to the JIRA I linked you to
>                           (https://issues.jboss.org/browse/APIMAN-516).
>             Because of
>                      the way the
>                           policy chain currently works the behaviour of
>             CORS is
>                      invalid in a
>                           few very specific cases (e.g. when you stack
>             it with an auth
>                           policy). I'll let you know when it's fixed.
>
>                           Regards,
>                           Marc
>
>                           On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                               I have a problem in calling a service in
>             apiman-gateway
>                      with the
>                               Authorization: Bearer <token> in the header.
>
>                               It seems to preflight OPTIONS and return
>
>                                 1.
>                                    X-Policy-Failure-Message:
>                                    OAuth2 'Authorization' header or
>             'access_token' query
>                               parameter must
>                                    be provided.
>
>                               I am sending the bearer token with the
>             request and i
>                      make sure
>                               in the
>                               preflight its sent in the request.
>
>                                 1.
>                                    Access-Control-Request-Headers:
>                                    accept, authorization
>
>                               Does anyone know if there Is something i'm
>             missing ?
>                      do i need
>                               to get
>                               authorization enabled or added anywhere ?
>             as a side
>                      note i have
>                               below in
>                               my api as well:
>
>
>               response.setHeader("Access-Control-Allow-Headers",
>                      "Authorization");
>
>
>
>               _______________________________________________
>                               Apiman-user mailing list
>             Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                      <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                      <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>
>
>


From fadiabdeen at gmail.com  Wed Aug 19 09:02:24 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Wed, 19 Aug 2015 09:02:24 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D45201.9060907@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
Message-ID: <CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>

So what it seems like is that we have to use CORS Policy and add it before
the Keycloak authentication policy in order for my preflight to pass ..
thats the part i was missing completely . i'm not sure if its should be
considered a bug or flexibility to do what we want .. But thanks for the
explaination Marc.

Anyway .. i'm still having a problem with CORS Policy, probably I just dont
have the latest code. i added some details to the JIRA ticket

On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com> wrote:

> I replicated your set up as far as I could, and I couldn't replicate your
> issue (perhaps your CORS setup is wrong?). Please see the JIRA comments and
> screenshots - https://issues.jboss.org/browse/APIMAN-516
>
> Either way, I also fixed a bug unrelated to your problem, so please
> re-build the plugins before trying again :-).
>
> On 18/08/2015 19:25, Fadi Abdin wrote:
>
>> It did not work .
>>
>> I setup everything they way you told me Marc and i'm testing it on my
>> local.
>> It seems its sending that preflight OPTIONS and coming back with 401 still
>>
>> On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin <fadiabdeen at gmail.com
>> <mailto:fadiabdeen at gmail.com>> wrote:
>>
>>     I'm still working on it :( .. i had to give the network guys few ip
>>     addresses to whitelist so i can mvn install .. ... almost there.
>>
>>     On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy <marc.savy at redhat.com
>>     <mailto:marc.savy at redhat.com>> wrote:
>>
>>         My pleasure! Did it work?
>>
>>         On 17/08/2015 16:38, Fadi Abdin wrote:
>>
>>             cool .. you're the man ;)
>>
>>
>>             On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>>             wrote:
>>
>>                  I'm actually testing the fix right now. It will land
>>             both on the 1.2.x
>>                  branch and the 1.1.x branch shortly. You should be able
>>             to test it out
>>                  in a short while: I'll send you an email when it's
>>             available.
>>
>>                  On 17/08/2015 16:23, Fadi Abdin wrote:
>>
>>                      Thank you Marc,
>>                      Is there a work around that you can think of ?
>>                      I'm doing it with angularjs  , very simple
>>
>>                      $http({method: 'GET', url:
>>             'http://server/apiman-gateway/service',
>>                      headers: {
>>                            'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>                      });
>>
>>                      I assume you will fix it in the new version , right?
>>
>>
>>
>>                      On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>                      <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>>                      <mailto:marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>             <mailto:marc.savy at redhat.com>>>> wrote:
>>
>>                           Hi,
>>
>>                           This is related to the JIRA I linked you to
>>                           (https://issues.jboss.org/browse/APIMAN-516).
>>             Because of
>>                      the way the
>>                           policy chain currently works the behaviour of
>>             CORS is
>>                      invalid in a
>>                           few very specific cases (e.g. when you stack
>>             it with an auth
>>                           policy). I'll let you know when it's fixed.
>>
>>                           Regards,
>>                           Marc
>>
>>                           On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>                               I have a problem in calling a service in
>>             apiman-gateway
>>                      with the
>>                               Authorization: Bearer <token> in the header.
>>
>>                               It seems to preflight OPTIONS and return
>>
>>                                 1.
>>                                    X-Policy-Failure-Message:
>>                                    OAuth2 'Authorization' header or
>>             'access_token' query
>>                               parameter must
>>                                    be provided.
>>
>>                               I am sending the bearer token with the
>>             request and i
>>                      make sure
>>                               in the
>>                               preflight its sent in the request.
>>
>>                                 1.
>>                                    Access-Control-Request-Headers:
>>                                    accept, authorization
>>
>>                               Does anyone know if there Is something i'm
>>             missing ?
>>                      do i need
>>                               to get
>>                               authorization enabled or added anywhere ?
>>             as a side
>>                      note i have
>>                               below in
>>                               my api as well:
>>
>>
>>               response.setHeader("Access-Control-Allow-Headers",
>>                      "Authorization");
>>
>>
>>
>>               _______________________________________________
>>                               Apiman-user mailing list
>>             Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>
>>             <mailto:Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>>
>>                      <mailto:Apiman-user at lists.jboss.org
>>             <mailto:Apiman-user at lists.jboss.org>
>>                      <mailto:Apiman-user at lists.jboss.org
>>             <mailto: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/20150819/092530f4/attachment-0001.html 

From marc.savy at redhat.com  Wed Aug 19 09:09:57 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 14:09:57 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
Message-ID: <55D48025.2020100@redhat.com>

What you're doing will always require a CORS preflight request (due to the non-simple headers), and I'm not sure it makes sense for us as an API gateway to funnel through CORS Preflight requests to the service by default. It complicates things when you start thinking about metering, security, etc.

Eric, what do you think?

On 19/08/2015 14:02, Fadi Abdin wrote:
> So what it seems like is that we have to use CORS Policy and add it
> before the Keycloak authentication policy in order for my preflight to
> pass .. thats the part i was missing completely . i'm not sure if its
> should be considered a bug or flexibility to do what we want .. But
> thanks for the explaination Marc.
>
> Anyway .. i'm still having a problem with CORS Policy, probably I just
> dont have the latest code. i added some details to the JIRA ticket
>
> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I replicated your set up as far as I could, and I couldn't replicate
>     your issue (perhaps your CORS setup is wrong?). Please see the JIRA
>     comments and screenshots - https://issues.jboss.org/browse/APIMAN-516
>
>     Either way, I also fixed a bug unrelated to your problem, so please
>     re-build the plugins before trying again :-).
>
>     On 18/08/2015 19:25, Fadi Abdin wrote:
>
>         It did not work .
>
>         I setup everything they way you told me Marc and i'm testing it
>         on my
>         local.
>         It seems its sending that preflight OPTIONS and coming back with
>         401 still
>
>         On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
>         <fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>
>         <mailto:fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>>> wrote:
>
>              I'm still working on it :( .. i had to give the network
>         guys few ip
>              addresses to whitelist so i can mvn install .. ... almost
>         there.
>
>              On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
>         <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>              <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>> wrote:
>
>                  My pleasure! Did it work?
>
>                  On 17/08/2015 16:38, Fadi Abdin wrote:
>
>                      cool .. you're the man ;)
>
>
>                      On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>                      <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>         <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                      <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>>>
>                      wrote:
>
>                           I'm actually testing the fix right now. It
>         will land
>                      both on the 1.2.x
>                           branch and the 1.1.x branch shortly. You
>         should be able
>                      to test it out
>                           in a short while: I'll send you an email when it's
>                      available.
>
>                           On 17/08/2015 16:23, Fadi Abdin wrote:
>
>                               Thank you Marc,
>                               Is there a work around that you can think of ?
>                               I'm doing it with angularjs  , very simple
>
>                               $http({method: 'GET', url:
>                      'http://server/apiman-gateway/service',
>                               headers: {
>                                     'Authorization': 'Bearer XXXXXXXXXXXXX'}
>                               });
>
>                               I assume you will fix it in the new
>         version , right?
>
>
>
>                               On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>                               <marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>
>                      <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>>
>                               <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>
>                      <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>
>                      <mailto:marc.savy at redhat.com
>         <mailto:marc.savy at redhat.com>>>>> wrote:
>
>                                    Hi,
>
>                                    This is related to the JIRA I linked
>         you to
>
>         (https://issues.jboss.org/browse/APIMAN-516).
>                      Because of
>                               the way the
>                                    policy chain currently works the
>         behaviour of
>                      CORS is
>                               invalid in a
>                                    few very specific cases (e.g. when
>         you stack
>                      it with an auth
>                                    policy). I'll let you know when it's
>         fixed.
>
>                                    Regards,
>                                    Marc
>
>                                    On 17/08/2015 15:44, Fadi Abdin wrote:
>
>                                        I have a problem in calling a
>         service in
>                      apiman-gateway
>                               with the
>                                        Authorization: Bearer <token> in
>         the header.
>
>                                        It seems to preflight OPTIONS and
>         return
>
>                                          1.
>                                             X-Policy-Failure-Message:
>                                             OAuth2 'Authorization' header or
>                      'access_token' query
>                                        parameter must
>                                             be provided.
>
>                                        I am sending the bearer token
>         with the
>                      request and i
>                               make sure
>                                        in the
>                                        preflight its sent in the request.
>
>                                          1.
>                                             Access-Control-Request-Headers:
>                                             accept, authorization
>
>                                        Does anyone know if there Is
>         something i'm
>                      missing ?
>                               do i need
>                                        to get
>                                        authorization enabled or added
>         anywhere ?
>                      as a side
>                               note i have
>                                        below in
>                                        my api as well:
>
>
>                        response.setHeader("Access-Control-Allow-Headers",
>                               "Authorization");
>
>
>
>                        _______________________________________________
>                                        Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>                      <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>                      <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>
>                      <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>>
>                               <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>
>                      <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>
>                               <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>
>                      <mailto:Apiman-user at lists.jboss.org
>         <mailto:Apiman-user at lists.jboss.org>>>>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>
>
>
>
>
>


From eric.wittmann at redhat.com  Wed Aug 19 09:16:55 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 19 Aug 2015 09:16:55 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D48025.2020100@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com>
Message-ID: <55D481C7.1040403@redhat.com>

I think that if apiman is being asked to do Authentication *and* CORS is 
required by the client, then apiman will have to do both.

I think that's desirable anyway - it allows the back end service 
implementation to not worry about supporting CORS.  It's a win-win.

-Eric

On 8/19/2015 9:09 AM, Marc Savy wrote:
> What you're doing will always require a CORS preflight request (due to the non-simple headers), and I'm not sure it makes sense for us as an API gateway to funnel through CORS Preflight requests to the service by default. It complicates things when you start thinking about metering, security, etc.
>
> Eric, what do you think?
>
> On 19/08/2015 14:02, Fadi Abdin wrote:
>> So what it seems like is that we have to use CORS Policy and add it
>> before the Keycloak authentication policy in order for my preflight to
>> pass .. thats the part i was missing completely . i'm not sure if its
>> should be considered a bug or flexibility to do what we want .. But
>> thanks for the explaination Marc.
>>
>> Anyway .. i'm still having a problem with CORS Policy, probably I just
>> dont have the latest code. i added some details to the JIRA ticket
>>
>> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>> wrote:
>>
>>      I replicated your set up as far as I could, and I couldn't replicate
>>      your issue (perhaps your CORS setup is wrong?). Please see the JIRA
>>      comments and screenshots - https://issues.jboss.org/browse/APIMAN-516
>>
>>      Either way, I also fixed a bug unrelated to your problem, so please
>>      re-build the plugins before trying again :-).
>>
>>      On 18/08/2015 19:25, Fadi Abdin wrote:
>>
>>          It did not work .
>>
>>          I setup everything they way you told me Marc and i'm testing it
>>          on my
>>          local.
>>          It seems its sending that preflight OPTIONS and coming back with
>>          401 still
>>
>>          On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
>>          <fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>
>>          <mailto:fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>>> wrote:
>>
>>               I'm still working on it :( .. i had to give the network
>>          guys few ip
>>               addresses to whitelist so i can mvn install .. ... almost
>>          there.
>>
>>               On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
>>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>               <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>>> wrote:
>>
>>                   My pleasure! Did it work?
>>
>>                   On 17/08/2015 16:38, Fadi Abdin wrote:
>>
>>                       cool .. you're the man ;)
>>
>>
>>                       On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>>                       <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>>                       <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>>>>
>>                       wrote:
>>
>>                            I'm actually testing the fix right now. It
>>          will land
>>                       both on the 1.2.x
>>                            branch and the 1.1.x branch shortly. You
>>          should be able
>>                       to test it out
>>                            in a short while: I'll send you an email when it's
>>                       available.
>>
>>                            On 17/08/2015 16:23, Fadi Abdin wrote:
>>
>>                                Thank you Marc,
>>                                Is there a work around that you can think of ?
>>                                I'm doing it with angularjs  , very simple
>>
>>                                $http({method: 'GET', url:
>>                       'http://server/apiman-gateway/service',
>>                                headers: {
>>                                      'Authorization': 'Bearer XXXXXXXXXXXXX'}
>>                                });
>>
>>                                I assume you will fix it in the new
>>          version , right?
>>
>>
>>
>>                                On Mon, Aug 17, 2015 at 10:52 AM, Marc Savy
>>                                <marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>>
>>                       <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>>>
>>                                <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>
>>                       <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>
>>                       <mailto:marc.savy at redhat.com
>>          <mailto:marc.savy at redhat.com>>>>> wrote:
>>
>>                                     Hi,
>>
>>                                     This is related to the JIRA I linked
>>          you to
>>
>>          (https://issues.jboss.org/browse/APIMAN-516).
>>                       Because of
>>                                the way the
>>                                     policy chain currently works the
>>          behaviour of
>>                       CORS is
>>                                invalid in a
>>                                     few very specific cases (e.g. when
>>          you stack
>>                       it with an auth
>>                                     policy). I'll let you know when it's
>>          fixed.
>>
>>                                     Regards,
>>                                     Marc
>>
>>                                     On 17/08/2015 15:44, Fadi Abdin wrote:
>>
>>                                         I have a problem in calling a
>>          service in
>>                       apiman-gateway
>>                                with the
>>                                         Authorization: Bearer <token> in
>>          the header.
>>
>>                                         It seems to preflight OPTIONS and
>>          return
>>
>>                                           1.
>>                                              X-Policy-Failure-Message:
>>                                              OAuth2 'Authorization' header or
>>                       'access_token' query
>>                                         parameter must
>>                                              be provided.
>>
>>                                         I am sending the bearer token
>>          with the
>>                       request and i
>>                                make sure
>>                                         in the
>>                                         preflight its sent in the request.
>>
>>                                           1.
>>                                              Access-Control-Request-Headers:
>>                                              accept, authorization
>>
>>                                         Does anyone know if there Is
>>          something i'm
>>                       missing ?
>>                                do i need
>>                                         to get
>>                                         authorization enabled or added
>>          anywhere ?
>>                       as a side
>>                                note i have
>>                                         below in
>>                                         my api as well:
>>
>>
>>                         response.setHeader("Access-Control-Allow-Headers",
>>                                "Authorization");
>>
>>
>>
>>                         _______________________________________________
>>                                         Apiman-user mailing list
>>          Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>                       <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>>
>>                       <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>
>>                       <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>>>
>>                                <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>
>>                       <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>>
>>                                <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>
>>                       <mailto:Apiman-user at lists.jboss.org
>>          <mailto:Apiman-user at lists.jboss.org>>>>
>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Wed Aug 19 11:23:38 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 16:23:38 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <55D481C7.1040403@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
Message-ID: <55D49F7A.9050300@redhat.com>

I think case being suggested here is slightly different -

This is one where someone has selected an Auth policy on the gateway, but *not* a CORS policy - instead their back-end service supports CORS and they want the service to handle the preflight request directly. Should we pipeline the CORS preflight request through to the backend in that case (i.e. bypass auth)? I'd say no, probably.

Perhaps that's what you were getting at already!

On 19/08/2015 14:16, Eric Wittmann wrote:
> I think that if apiman is being asked to do Authentication *and* CORS is
> required by the client, then apiman will have to do both.
>
> I think that's desirable anyway - it allows the back end service
> implementation to not worry about supporting CORS.  It's a win-win.
>
> -Eric
>
> On 8/19/2015 9:09 AM, Marc Savy wrote:
> > What you're doing will always require a CORS preflight request (due to
> > the non-simple headers), and I'm not sure it makes sense for us as an
> > API gateway to funnel through CORS Preflight requests to the service
> > by default. It complicates things when you start thinking about
> > metering, security, etc.
> >
> > Eric, what do you think?
> >
> > On 19/08/2015 14:02, Fadi Abdin wrote:
> >> So what it seems like is that we have to use CORS Policy and add it
> >> before the Keycloak authentication policy in order for my preflight to
> >> pass .. thats the part i was missing completely . i'm not sure if its
> >> should be considered a bug or flexibility to do what we want .. But
> >> thanks for the explaination Marc.
> >>
> >> Anyway .. i'm still having a problem with CORS Policy, probably I just
> >> dont have the latest code. i added some details to the JIRA ticket
> >>
> >> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
> >> <mailto:marc.savy at redhat.com>> wrote:
> >>
> >>      I replicated your set up as far as I could, and I couldn't
> >> replicate
> >>      your issue (perhaps your CORS setup is wrong?). Please see the JIRA
> >>      comments and screenshots -
> >> https://issues.jboss.org/browse/APIMAN-516
> >>
> >>      Either way, I also fixed a bug unrelated to your problem, so please
> >>      re-build the plugins before trying again :-).
> >>
> >>      On 18/08/2015 19:25, Fadi Abdin wrote:
> >>
> >>          It did not work .
> >>
> >>          I setup everything they way you told me Marc and i'm testing it
> >>          on my
> >>          local.
> >>          It seems its sending that preflight OPTIONS and coming back
> >> with
> >>          401 still
> >>
> >>          On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
> >>          <fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>
> >>          <mailto:fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>>>
> >> wrote:
> >>
> >>               I'm still working on it :( .. i had to give the network
> >>          guys few ip
> >>               addresses to whitelist so i can mvn install .. ... almost
> >>          there.
> >>
> >>               On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
> >>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
> >>               <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>>> wrote:
> >>
> >>                   My pleasure! Did it work?
> >>
> >>                   On 17/08/2015 16:38, Fadi Abdin wrote:
> >>
> >>                       cool .. you're the man ;)
> >>
> >>
> >>                       On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
> >>                       <marc.savy at redhat.com
> >> <mailto:marc.savy at redhat.com>
> >>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
> >>                       <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>>>>
> >>                       wrote:
> >>
> >>                            I'm actually testing the fix right now. It
> >>          will land
> >>                       both on the 1.2.x
> >>                            branch and the 1.1.x branch shortly. You
> >>          should be able
> >>                       to test it out
> >>                            in a short while: I'll send you an email
> >> when it's
> >>                       available.
> >>
> >>                            On 17/08/2015 16:23, Fadi Abdin wrote:
> >>
> >>                                Thank you Marc,
> >>                                Is there a work around that you can
> >> think of ?
> >>                                I'm doing it with angularjs  , very
> >> simple
> >>
> >>                                $http({method: 'GET', url:
> >>                       'http://server/apiman-gateway/service',
> >>                                headers: {
> >>                                      'Authorization': 'Bearer
> >> XXXXXXXXXXXXX'}
> >>                                });
> >>
> >>                                I assume you will fix it in the new
> >>          version , right?
> >>
> >>
> >>
> >>                                On Mon, Aug 17, 2015 at 10:52 AM, Marc
> >> Savy
> >>                                <marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>>
> >>                       <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>>>
> >>                                <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>
> >>                       <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>
> >>                       <mailto:marc.savy at redhat.com
> >>          <mailto:marc.savy at redhat.com>>>>> wrote:
> >>
> >>                                     Hi,
> >>
> >>                                     This is related to the JIRA I linked
> >>          you to
> >>
> >>          (https://issues.jboss.org/browse/APIMAN-516).
> >>                       Because of
> >>                                the way the
> >>                                     policy chain currently works the
> >>          behaviour of
> >>                       CORS is
> >>                                invalid in a
> >>                                     few very specific cases (e.g. when
> >>          you stack
> >>                       it with an auth
> >>                                     policy). I'll let you know when it's
> >>          fixed.
> >>
> >>                                     Regards,
> >>                                     Marc
> >>
> >>                                     On 17/08/2015 15:44, Fadi Abdin
> >> wrote:
> >>
> >>                                         I have a problem in calling a
> >>          service in
> >>                       apiman-gateway
> >>                                with the
> >>                                         Authorization: Bearer <token> in
> >>          the header.
> >>
> >>                                         It seems to preflight OPTIONS
> >> and
> >>          return
> >>
> >>                                           1.
> >>                                              X-Policy-Failure-Message:
> >>                                              OAuth2 'Authorization'
> >> header or
> >>                       'access_token' query
> >>                                         parameter must
> >>                                              be provided.
> >>
> >>                                         I am sending the bearer token
> >>          with the
> >>                       request and i
> >>                                make sure
> >>                                         in the
> >>                                         preflight its sent in the
> >> request.
> >>
> >>                                           1.
> >>
> >> Access-Control-Request-Headers:
> >>                                              accept, authorization
> >>
> >>                                         Does anyone know if there Is
> >>          something i'm
> >>                       missing ?
> >>                                do i need
> >>                                         to get
> >>                                         authorization enabled or added
> >>          anywhere ?
> >>                       as a side
> >>                                note i have
> >>                                         below in
> >>                                         my api as well:
> >>
> >>
> >>
> >> response.setHeader("Access-Control-Allow-Headers",
> >>                                "Authorization");
> >>
> >>
> >>
> >>                         _______________________________________________
> >>                                         Apiman-user mailing list
> >>          Apiman-user at lists.jboss.org
> >> <mailto:Apiman-user at lists.jboss.org>
> >>                       <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>>
> >>                       <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>
> >>                       <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>>>
> >>                                <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>
> >>                       <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>>
> >>                                <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>
> >>                       <mailto:Apiman-user at lists.jboss.org
> >>          <mailto:Apiman-user at lists.jboss.org>>>>
> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >


From eric.wittmann at redhat.com  Wed Aug 19 11:55:38 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 19 Aug 2015 11:55:38 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <55D49F7A.9050300@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com>
Message-ID: <55D4A6FA.1020109@redhat.com>

That is exactly what I was getting at.  If you have apiman performing 
authentication, then apiman MUST ALSO perform CORS for you. 
Specifically for the reason you say:  we don't want to skip 
authentication for OPTIONS requests.

That said, we *could* add another option to all the authentication 
policies, allowing auth to be skipped for specific VERBs.  That could be 
a reasonable feature.  I don't think I'm in favor of it though.

Instead, CORS functionality should be moved out of the back-end system 
and handled in apiman.

-Eric

On 8/19/2015 11:23 AM, Marc Savy wrote:
> I think case being suggested here is slightly different -
>
> This is one where someone has selected an Auth policy on the gateway,
> but *not* a CORS policy - instead their back-end service supports CORS
> and they want the service to handle the preflight request directly.
> Should we pipeline the CORS preflight request through to the backend in
> that case (i.e. bypass auth)? I'd say no, probably.
>
> Perhaps that's what you were getting at already!
>
> On 19/08/2015 14:16, Eric Wittmann wrote:
>> I think that if apiman is being asked to do Authentication *and* CORS is
>> required by the client, then apiman will have to do both.
>>
>> I think that's desirable anyway - it allows the back end service
>> implementation to not worry about supporting CORS.  It's a win-win.
>>
>> -Eric
>>
>> On 8/19/2015 9:09 AM, Marc Savy wrote:
>> > What you're doing will always require a CORS preflight request (due to
>> > the non-simple headers), and I'm not sure it makes sense for us as an
>> > API gateway to funnel through CORS Preflight requests to the service
>> > by default. It complicates things when you start thinking about
>> > metering, security, etc.
>> >
>> > Eric, what do you think?
>> >
>> > On 19/08/2015 14:02, Fadi Abdin wrote:
>> >> So what it seems like is that we have to use CORS Policy and add it
>> >> before the Keycloak authentication policy in order for my preflight to
>> >> pass .. thats the part i was missing completely . i'm not sure if its
>> >> should be considered a bug or flexibility to do what we want .. But
>> >> thanks for the explaination Marc.
>> >>
>> >> Anyway .. i'm still having a problem with CORS Policy, probably I just
>> >> dont have the latest code. i added some details to the JIRA ticket
>> >>
>> >> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
>> >> <mailto:marc.savy at redhat.com>> wrote:
>> >>
>> >>      I replicated your set up as far as I could, and I couldn't
>> >> replicate
>> >>      your issue (perhaps your CORS setup is wrong?). Please see the
>> JIRA
>> >>      comments and screenshots -
>> >> https://issues.jboss.org/browse/APIMAN-516
>> >>
>> >>      Either way, I also fixed a bug unrelated to your problem, so
>> please
>> >>      re-build the plugins before trying again :-).
>> >>
>> >>      On 18/08/2015 19:25, Fadi Abdin wrote:
>> >>
>> >>          It did not work .
>> >>
>> >>          I setup everything they way you told me Marc and i'm
>> testing it
>> >>          on my
>> >>          local.
>> >>          It seems its sending that preflight OPTIONS and coming back
>> >> with
>> >>          401 still
>> >>
>> >>          On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
>> >>          <fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>
>> >>          <mailto:fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>>>
>> >> wrote:
>> >>
>> >>               I'm still working on it :( .. i had to give the network
>> >>          guys few ip
>> >>               addresses to whitelist so i can mvn install .. ...
>> almost
>> >>          there.
>> >>
>> >>               On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
>> >>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>> >>               <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>>> wrote:
>> >>
>> >>                   My pleasure! Did it work?
>> >>
>> >>                   On 17/08/2015 16:38, Fadi Abdin wrote:
>> >>
>> >>                       cool .. you're the man ;)
>> >>
>> >>
>> >>                       On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
>> >>                       <marc.savy at redhat.com
>> >> <mailto:marc.savy at redhat.com>
>> >>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>> >>                       <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>>>>
>> >>                       wrote:
>> >>
>> >>                            I'm actually testing the fix right now. It
>> >>          will land
>> >>                       both on the 1.2.x
>> >>                            branch and the 1.1.x branch shortly. You
>> >>          should be able
>> >>                       to test it out
>> >>                            in a short while: I'll send you an email
>> >> when it's
>> >>                       available.
>> >>
>> >>                            On 17/08/2015 16:23, Fadi Abdin wrote:
>> >>
>> >>                                Thank you Marc,
>> >>                                Is there a work around that you can
>> >> think of ?
>> >>                                I'm doing it with angularjs  , very
>> >> simple
>> >>
>> >>                                $http({method: 'GET', url:
>> >>                       'http://server/apiman-gateway/service',
>> >>                                headers: {
>> >>                                      'Authorization': 'Bearer
>> >> XXXXXXXXXXXXX'}
>> >>                                });
>> >>
>> >>                                I assume you will fix it in the new
>> >>          version , right?
>> >>
>> >>
>> >>
>> >>                                On Mon, Aug 17, 2015 at 10:52 AM, Marc
>> >> Savy
>> >>                                <marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>>
>> >>                       <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>>>
>> >>                                <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>
>> >>                       <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>
>> >>                       <mailto:marc.savy at redhat.com
>> >>          <mailto:marc.savy at redhat.com>>>>> wrote:
>> >>
>> >>                                     Hi,
>> >>
>> >>                                     This is related to the JIRA I
>> linked
>> >>          you to
>> >>
>> >>          (https://issues.jboss.org/browse/APIMAN-516).
>> >>                       Because of
>> >>                                the way the
>> >>                                     policy chain currently works the
>> >>          behaviour of
>> >>                       CORS is
>> >>                                invalid in a
>> >>                                     few very specific cases (e.g. when
>> >>          you stack
>> >>                       it with an auth
>> >>                                     policy). I'll let you know when
>> it's
>> >>          fixed.
>> >>
>> >>                                     Regards,
>> >>                                     Marc
>> >>
>> >>                                     On 17/08/2015 15:44, Fadi Abdin
>> >> wrote:
>> >>
>> >>                                         I have a problem in calling a
>> >>          service in
>> >>                       apiman-gateway
>> >>                                with the
>> >>                                         Authorization: Bearer
>> <token> in
>> >>          the header.
>> >>
>> >>                                         It seems to preflight OPTIONS
>> >> and
>> >>          return
>> >>
>> >>                                           1.
>> >>                                              X-Policy-Failure-Message:
>> >>                                              OAuth2 'Authorization'
>> >> header or
>> >>                       'access_token' query
>> >>                                         parameter must
>> >>                                              be provided.
>> >>
>> >>                                         I am sending the bearer token
>> >>          with the
>> >>                       request and i
>> >>                                make sure
>> >>                                         in the
>> >>                                         preflight its sent in the
>> >> request.
>> >>
>> >>                                           1.
>> >>
>> >> Access-Control-Request-Headers:
>> >>                                              accept, authorization
>> >>
>> >>                                         Does anyone know if there Is
>> >>          something i'm
>> >>                       missing ?
>> >>                                do i need
>> >>                                         to get
>> >>                                         authorization enabled or added
>> >>          anywhere ?
>> >>                       as a side
>> >>                                note i have
>> >>                                         below in
>> >>                                         my api as well:
>> >>
>> >>
>> >>
>> >> response.setHeader("Access-Control-Allow-Headers",
>> >>                                "Authorization");
>> >>
>> >>
>> >>
>> >>
>> _______________________________________________
>> >>                                         Apiman-user mailing list
>> >>          Apiman-user at lists.jboss.org
>> >> <mailto:Apiman-user at lists.jboss.org>
>> >>                       <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>>
>> >>                       <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>
>> >>                       <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>>>
>> >>                                <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>
>> >>                       <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>>
>> >>                                <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>
>> >>                       <mailto:Apiman-user at lists.jboss.org
>> >>          <mailto:Apiman-user at lists.jboss.org>>>>
>> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>

From marc.savy at redhat.com  Wed Aug 19 11:58:52 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 16:58:52 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <55D4A6FA.1020109@redhat.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com> <55D4A6FA.1020109@redhat.com>
Message-ID: <55D4A7BC.2060103@redhat.com>

I agree - I don't see any compelling reason to add that kind of complexity for that case. I'm willing to be convinced, though.

On 19/08/2015 16:55, Eric Wittmann wrote:
> That is exactly what I was getting at.  If you have apiman performing
> authentication, then apiman MUST ALSO perform CORS for you. Specifically
> for the reason you say:  we don't want to skip authentication for
> OPTIONS requests.
>
> That said, we *could* add another option to all the authentication
> policies, allowing auth to be skipped for specific VERBs.  That could be
> a reasonable feature.  I don't think I'm in favor of it though.
>
> Instead, CORS functionality should be moved out of the back-end system
> and handled in apiman.
>
> -Eric
>
> On 8/19/2015 11:23 AM, Marc Savy wrote:
> > I think case being suggested here is slightly different -
> >
> > This is one where someone has selected an Auth policy on the gateway,
> > but *not* a CORS policy - instead their back-end service supports CORS
> > and they want the service to handle the preflight request directly.
> > Should we pipeline the CORS preflight request through to the backend in
> > that case (i.e. bypass auth)? I'd say no, probably.
> >
> > Perhaps that's what you were getting at already!
> >
> > On 19/08/2015 14:16, Eric Wittmann wrote:
> >> I think that if apiman is being asked to do Authentication *and* CORS is
> >> required by the client, then apiman will have to do both.
> >>
> >> I think that's desirable anyway - it allows the back end service
> >> implementation to not worry about supporting CORS.  It's a win-win.
> >>
> >> -Eric
> >>
> >> On 8/19/2015 9:09 AM, Marc Savy wrote:
> >> > What you're doing will always require a CORS preflight request (due to
> >> > the non-simple headers), and I'm not sure it makes sense for us as an
> >> > API gateway to funnel through CORS Preflight requests to the service
> >> > by default. It complicates things when you start thinking about
> >> > metering, security, etc.
> >> >
> >> > Eric, what do you think?
> >> >
> >> > On 19/08/2015 14:02, Fadi Abdin wrote:
> >> >> So what it seems like is that we have to use CORS Policy and add it
> >> >> before the Keycloak authentication policy in order for my
> >> preflight to
> >> >> pass .. thats the part i was missing completely . i'm not sure if its
> >> >> should be considered a bug or flexibility to do what we want .. But
> >> >> thanks for the explaination Marc.
> >> >>
> >> >> Anyway .. i'm still having a problem with CORS Policy, probably I
> >> just
> >> >> dont have the latest code. i added some details to the JIRA ticket
> >> >>
> >> >> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
> >> >> <mailto:marc.savy at redhat.com>> wrote:
> >> >>
> >> >>      I replicated your set up as far as I could, and I couldn't
> >> >> replicate
> >> >>      your issue (perhaps your CORS setup is wrong?). Please see the
> >> JIRA
> >> >>      comments and screenshots -
> >> >> https://issues.jboss.org/browse/APIMAN-516
> >> >>
> >> >>      Either way, I also fixed a bug unrelated to your problem, so
> >> please
> >> >>      re-build the plugins before trying again :-).
> >> >>
> >> >>      On 18/08/2015 19:25, Fadi Abdin wrote:
> >> >>
> >> >>          It did not work .
> >> >>
> >> >>          I setup everything they way you told me Marc and i'm
> >> testing it
> >> >>          on my
> >> >>          local.
> >> >>          It seems its sending that preflight OPTIONS and coming back
> >> >> with
> >> >>          401 still
> >> >>
> >> >>          On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
> >> >>          <fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>
> >> >>          <mailto:fadiabdeen at gmail.com <mailto:fadiabdeen at gmail.com>>>
> >> >> wrote:
> >> >>
> >> >>               I'm still working on it :( .. i had to give the network
> >> >>          guys few ip
> >> >>               addresses to whitelist so i can mvn install .. ...
> >> almost
> >> >>          there.
> >> >>
> >> >>               On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
> >> >>          <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
> >> >>               <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>>> wrote:
> >> >>
> >> >>                   My pleasure! Did it work?
> >> >>
> >> >>                   On 17/08/2015 16:38, Fadi Abdin wrote:
> >> >>
> >> >>                       cool .. you're the man ;)
> >> >>
> >> >>
> >> >>                       On Mon, Aug 17, 2015 at 11:37 AM, Marc Savy
> >> >>                       <marc.savy at redhat.com
> >> >> <mailto:marc.savy at redhat.com>
> >> >>          <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
> >> >>                       <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>>>>
> >> >>                       wrote:
> >> >>
> >> >>                            I'm actually testing the fix right now. It
> >> >>          will land
> >> >>                       both on the 1.2.x
> >> >>                            branch and the 1.1.x branch shortly. You
> >> >>          should be able
> >> >>                       to test it out
> >> >>                            in a short while: I'll send you an email
> >> >> when it's
> >> >>                       available.
> >> >>
> >> >>                            On 17/08/2015 16:23, Fadi Abdin wrote:
> >> >>
> >> >>                                Thank you Marc,
> >> >>                                Is there a work around that you can
> >> >> think of ?
> >> >>                                I'm doing it with angularjs  , very
> >> >> simple
> >> >>
> >> >>                                $http({method: 'GET', url:
> >> >>                       'http://server/apiman-gateway/service',
> >> >>                                headers: {
> >> >>                                      'Authorization': 'Bearer
> >> >> XXXXXXXXXXXXX'}
> >> >>                                });
> >> >>
> >> >>                                I assume you will fix it in the new
> >> >>          version , right?
> >> >>
> >> >>
> >> >>
> >> >>                                On Mon, Aug 17, 2015 at 10:52 AM, Marc
> >> >> Savy
> >> >>                                <marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>>
> >> >>                       <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>>>
> >> >>                                <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>
> >> >>                       <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>
> >> >>                       <mailto:marc.savy at redhat.com
> >> >>          <mailto:marc.savy at redhat.com>>>>> wrote:
> >> >>
> >> >>                                     Hi,
> >> >>
> >> >>                                     This is related to the JIRA I
> >> linked
> >> >>          you to
> >> >>
> >> >>          (https://issues.jboss.org/browse/APIMAN-516).
> >> >>                       Because of
> >> >>                                the way the
> >> >>                                     policy chain currently works the
> >> >>          behaviour of
> >> >>                       CORS is
> >> >>                                invalid in a
> >> >>                                     few very specific cases (e.g.
> >> when
> >> >>          you stack
> >> >>                       it with an auth
> >> >>                                     policy). I'll let you know when
> >> it's
> >> >>          fixed.
> >> >>
> >> >>                                     Regards,
> >> >>                                     Marc
> >> >>
> >> >>                                     On 17/08/2015 15:44, Fadi Abdin
> >> >> wrote:
> >> >>
> >> >>                                         I have a problem in calling a
> >> >>          service in
> >> >>                       apiman-gateway
> >> >>                                with the
> >> >>                                         Authorization: Bearer
> >> <token> in
> >> >>          the header.
> >> >>
> >> >>                                         It seems to preflight OPTIONS
> >> >> and
> >> >>          return
> >> >>
> >> >>                                           1.
> >> >>
> >> X-Policy-Failure-Message:
> >> >>                                              OAuth2 'Authorization'
> >> >> header or
> >> >>                       'access_token' query
> >> >>                                         parameter must
> >> >>                                              be provided.
> >> >>
> >> >>                                         I am sending the bearer token
> >> >>          with the
> >> >>                       request and i
> >> >>                                make sure
> >> >>                                         in the
> >> >>                                         preflight its sent in the
> >> >> request.
> >> >>
> >> >>                                           1.
> >> >>
> >> >> Access-Control-Request-Headers:
> >> >>                                              accept, authorization
> >> >>
> >> >>                                         Does anyone know if there Is
> >> >>          something i'm
> >> >>                       missing ?
> >> >>                                do i need
> >> >>                                         to get
> >> >>                                         authorization enabled or
> >> added
> >> >>          anywhere ?
> >> >>                       as a side
> >> >>                                note i have
> >> >>                                         below in
> >> >>                                         my api as well:
> >> >>
> >> >>
> >> >>
> >> >> response.setHeader("Access-Control-Allow-Headers",
> >> >>                                "Authorization");
> >> >>
> >> >>
> >> >>
> >> >>
> >> _______________________________________________
> >> >>                                         Apiman-user mailing list
> >> >>          Apiman-user at lists.jboss.org
> >> >> <mailto:Apiman-user at lists.jboss.org>
> >> >>                       <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>>
> >> >>                       <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>
> >> >>                       <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>>>
> >> >>                                <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>
> >> >>                       <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>>
> >> >>                                <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>
> >> >>                       <mailto:Apiman-user at lists.jboss.org
> >> >>          <mailto:Apiman-user at lists.jboss.org>>>>
> >> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> > _______________________________________________
> >> > Apiman-user mailing list
> >> > Apiman-user at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >> >
> >


From marc.savy at redhat.com  Wed Aug 19 12:45:32 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 17:45:32 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0Q6oLsd=zFFMz+EbRyG1f6V+Nf0fztTUZLOyZSJOwOfhw@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com> <55D4A6FA.1020109@redhat.com>
	<55D4A7BC.2060103@redhat.com>
	<CABXXV0Q6oLsd=zFFMz+EbRyG1f6V+Nf0fztTUZLOyZSJOwOfhw@mail.gmail.com>
Message-ID: <55D4B2AC.5010508@redhat.com>

In many cases people are using non-browser applications (e.g. mobile, B2B, Java app...) which don't use CORS, so I don't think they are necessarily concomitant in all circumstances.

Certainly makes sense to document things if people are unaware.

On 19/08/2015 17:36, Fadi Abdin wrote:
> I think there is no need to relay on the API for the cors since it can
> be handled in the APIMan , but maybe something need to be indicated that
> the CORS Plugin must be installed and setup . at least in the UI , and
> ideally get installed with the Oauth plugin (keycloak) if its not there.
>
>
>
> On Wed, Aug 19, 2015 at 11:58 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I agree - I don't see any compelling reason to add that kind of
>     complexity for that case. I'm willing to be convinced, though.
>
>     On 19/08/2015 16:55, Eric Wittmann wrote:
>      > That is exactly what I was getting at.  If you have apiman performing
>      > authentication, then apiman MUST ALSO perform CORS for you.
>     Specifically
>      > for the reason you say:  we don't want to skip authentication for
>      > OPTIONS requests.
>      >
>      > That said, we *could* add another option to all the authentication
>      > policies, allowing auth to be skipped for specific VERBs.  That
>     could be
>      > a reasonable feature.  I don't think I'm in favor of it though.
>      >
>      > Instead, CORS functionality should be moved out of the back-end
>     system
>      > and handled in apiman.
>      >
>      > -Eric
>      >
>      > On 8/19/2015 11:23 AM, Marc Savy wrote:
>      > > I think case being suggested here is slightly different -
>      > >
>      > > This is one where someone has selected an Auth policy on the
>     gateway,
>      > > but *not* a CORS policy - instead their back-end service
>     supports CORS
>      > > and they want the service to handle the preflight request directly.
>      > > Should we pipeline the CORS preflight request through to the
>     backend in
>      > > that case (i.e. bypass auth)? I'd say no, probably.
>      > >
>      > > Perhaps that's what you were getting at already!
>      > >
>      > > On 19/08/2015 14:16, Eric Wittmann wrote:
>      > >> I think that if apiman is being asked to do Authentication
>     *and* CORS is
>      > >> required by the client, then apiman will have to do both.
>      > >>
>      > >> I think that's desirable anyway - it allows the back end service
>      > >> implementation to not worry about supporting CORS.  It's a
>     win-win.
>      > >>
>      > >> -Eric
>      > >>
>      > >> On 8/19/2015 9:09 AM, Marc Savy wrote:
>      > >> > What you're doing will always require a CORS preflight
>     request (due to
>      > >> > the non-simple headers), and I'm not sure it makes sense for
>     us as an
>      > >> > API gateway to funnel through CORS Preflight requests to the
>     service
>      > >> > by default. It complicates things when you start thinking about
>      > >> > metering, security, etc.
>      > >> >
>      > >> > Eric, what do you think?
>      > >> >
>      > >> > On 19/08/2015 14:02, Fadi Abdin wrote:
>      > >> >> So what it seems like is that we have to use CORS Policy
>     and add it
>      > >> >> before the Keycloak authentication policy in order for my
>      > >> preflight to
>      > >> >> pass .. thats the part i was missing completely . i'm not
>     sure if its
>      > >> >> should be considered a bug or flexibility to do what we
>     want .. But
>      > >> >> thanks for the explaination Marc.
>      > >> >>
>      > >> >> Anyway .. i'm still having a problem with CORS Policy,
>     probably I
>      > >> just
>      > >> >> dont have the latest code. i added some details to the JIRA
>     ticket
>      > >> >>
>      > >> >> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy
>     <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>      > >> >> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>> wrote:
>      > >> >>
>      > >> >>      I replicated your set up as far as I could, and I couldn't
>      > >> >> replicate
>      > >> >>      your issue (perhaps your CORS setup is wrong?). Please
>     see the
>      > >> JIRA
>      > >> >>      comments and screenshots -
>      > >> >> https://issues.jboss.org/browse/APIMAN-516
>      > >> >>
>      > >> >>      Either way, I also fixed a bug unrelated to your
>     problem, so
>      > >> please
>      > >> >>      re-build the plugins before trying again :-).
>      > >> >>
>      > >> >>      On 18/08/2015 19:25, Fadi Abdin wrote:
>      > >> >>
>      > >> >>          It did not work .
>      > >> >>
>      > >> >>          I setup everything they way you told me Marc and i'm
>      > >> testing it
>      > >> >>          on my
>      > >> >>          local.
>      > >> >>          It seems its sending that preflight OPTIONS and
>     coming back
>      > >> >> with
>      > >> >>          401 still
>      > >> >>
>      > >> >>          On Tue, Aug 18, 2015 at 10:48 AM, Fadi Abdin
>      > >> >>          <fadiabdeen at gmail.com
>     <mailto:fadiabdeen at gmail.com> <mailto:fadiabdeen at gmail.com
>     <mailto:fadiabdeen at gmail.com>>
>      > >> >>          <mailto:fadiabdeen at gmail.com
>     <mailto:fadiabdeen at gmail.com> <mailto:fadiabdeen at gmail.com
>     <mailto:fadiabdeen at gmail.com>>>>
>      > >> >> wrote:
>      > >> >>
>      > >> >>               I'm still working on it :( .. i had to give
>     the network
>      > >> >>          guys few ip
>      > >> >>               addresses to whitelist so i can mvn install
>     .. ...
>      > >> almost
>      > >> >>          there.
>      > >> >>
>      > >> >>               On Tue, Aug 18, 2015 at 9:46 AM, Marc Savy
>      > >> >>          <marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>
>      > >> >>               <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>> wrote:
>      > >> >>
>      > >> >>                   My pleasure! Did it work?
>      > >> >>
>      > >> >>                   On 17/08/2015 16:38, Fadi Abdin wrote:
>      > >> >>
>      > >> >>                       cool .. you're the man ;)
>      > >> >>
>      > >> >>
>      > >> >>                       On Mon, Aug 17, 2015 at 11:37 AM,
>     Marc Savy
>      > >> >>                       <marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >> <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>
>      > >> >>                       <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>>>
>      > >> >>                       wrote:
>      > >> >>
>      > >> >>                            I'm actually testing the fix
>     right now. It
>      > >> >>          will land
>      > >> >>                       both on the 1.2.x
>      > >> >>                            branch and the 1.1.x branch
>     shortly. You
>      > >> >>          should be able
>      > >> >>                       to test it out
>      > >> >>                            in a short while: I'll send you
>     an email
>      > >> >> when it's
>      > >> >>                       available.
>      > >> >>
>      > >> >>                            On 17/08/2015 16:23, Fadi Abdin
>     wrote:
>      > >> >>
>      > >> >>                                Thank you Marc,
>      > >> >>                                Is there a work around that
>     you can
>      > >> >> think of ?
>      > >> >>                                I'm doing it with angularjs
>     , very
>      > >> >> simple
>      > >> >>
>      > >> >>                                $http({method: 'GET', url:
>      > >> >>                       'http://server/apiman-gateway/service',
>      > >> >>                                headers: {
>      > >> >>                                      'Authorization': 'Bearer
>      > >> >> XXXXXXXXXXXXX'}
>      > >> >>                                });
>      > >> >>
>      > >> >>                                I assume you will fix it in
>     the new
>      > >> >>          version , right?
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>                                On Mon, Aug 17, 2015 at
>     10:52 AM, Marc
>      > >> >> Savy
>      > >> >>                                <marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>
>      > >> >>                       <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>>
>      > >> >>                                <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>
>      > >> >>                       <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>> <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>
>      > >> >>                       <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>
>      > >> >>          <mailto:marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>>>>>> wrote:
>      > >> >>
>      > >> >>                                     Hi,
>      > >> >>
>      > >> >>                                     This is related to the
>     JIRA I
>      > >> linked
>      > >> >>          you to
>      > >> >>
>      > >> >>          (https://issues.jboss.org/browse/APIMAN-516).
>      > >> >>                       Because of
>      > >> >>                                the way the
>      > >> >>                                     policy chain currently
>     works the
>      > >> >>          behaviour of
>      > >> >>                       CORS is
>      > >> >>                                invalid in a
>      > >> >>                                     few very specific cases
>     (e.g.
>      > >> when
>      > >> >>          you stack
>      > >> >>                       it with an auth
>      > >> >>                                     policy). I'll let you
>     know when
>      > >> it's
>      > >> >>          fixed.
>      > >> >>
>      > >> >>                                     Regards,
>      > >> >>                                     Marc
>      > >> >>
>      > >> >>                                     On 17/08/2015 15:44,
>     Fadi Abdin
>      > >> >> wrote:
>      > >> >>
>      > >> >>                                         I have a problem in
>     calling a
>      > >> >>          service in
>      > >> >>                       apiman-gateway
>      > >> >>                                with the
>      > >> >>                                         Authorization: Bearer
>      > >> <token> in
>      > >> >>          the header.
>      > >> >>
>      > >> >>                                         It seems to
>     preflight OPTIONS
>      > >> >> and
>      > >> >>          return
>      > >> >>
>      > >> >>                                           1.
>      > >> >>
>      > >> X-Policy-Failure-Message:
>      > >> >>                                              OAuth2
>     'Authorization'
>      > >> >> header or
>      > >> >>                       'access_token' query
>      > >> >>                                         parameter must
>      > >> >>                                              be provided.
>      > >> >>
>      > >> >>                                         I am sending the
>     bearer token
>      > >> >>          with the
>      > >> >>                       request and i
>      > >> >>                                make sure
>      > >> >>                                         in the
>      > >> >>                                         preflight its sent
>     in the
>      > >> >> request.
>      > >> >>
>      > >> >>                                           1.
>      > >> >>
>      > >> >> Access-Control-Request-Headers:
>      > >> >>                                              accept,
>     authorization
>      > >> >>
>      > >> >>                                         Does anyone know if
>     there Is
>      > >> >>          something i'm
>      > >> >>                       missing ?
>      > >> >>                                do i need
>      > >> >>                                         to get
>      > >> >>                                         authorization
>     enabled or
>      > >> added
>      > >> >>          anywhere ?
>      > >> >>                       as a side
>      > >> >>                                note i have
>      > >> >>                                         below in
>      > >> >>                                         my api as well:
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >> response.setHeader("Access-Control-Allow-Headers",
>      > >> >>                                "Authorization");
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> _______________________________________________
>      > >> >>                                         Apiman-user mailing
>     list
>      > >> >> Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >> <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>
>      > >> >>                       <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>>
>      > >> >>                       <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>
>      > >> >>                       <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>>>
>      > >> >>
>     <mailto:Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>
>      > >> >>                       <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>>
>      > >> >>
>     <mailto:Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>
>      > >> >>                       <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>
>      > >> >>          <mailto:Apiman-user at lists.jboss.org
>     <mailto:Apiman-user at lists.jboss.org>>>>>
>      > >> >> https://lists.jboss.org/mailman/listinfo/apiman-user
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >>
>      > >> >
>      > >> > _______________________________________________
>      > >> > Apiman-user mailing list
>      > >> > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>      > >> > https://lists.jboss.org/mailman/listinfo/apiman-user
>      > >> >
>      > >
>
>     _______________________________________________
>     Apiman-user mailing list
>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/apiman-user
>
>


From marc.savy at redhat.com  Wed Aug 19 13:25:39 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 19 Aug 2015 18:25:39 +0100
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0S5jfpRdLmkM-nijf6FyHH_L9_H7V+v=Z2MNUhrVmyZPw@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1F518.2080804@redhat.com>
	<CABXXV0Rt55Ja0H8PVTQQWJ+G+2WP_EmdyyO-UAtAc4JN4oFRSA@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com> <55D4A6FA.1020109@redhat.com>
	<55D4A7BC.2060103@redhat.com>
	<CABXXV0Q6oLsd=zFFMz+EbRyG1f6V+Nf0fztTUZLOyZSJOwOfhw@mail.gmail.com>
	<55D4B2AC.5010508@redhat.com>
	<CABXXV0SL=4bcH-yss0kTRge+Fxc-hd3jNtZ5BkZcU2-FGBTo_g@mail.gmail.com>
	<CABXXV0S5jfpRdLmkM-nijf6FyHH_L9_H7V+v=Z2MNUhrVmyZPw@mail.gmail.com>
Message-ID: <55D4BC13.90305@redhat.com>

The error information implies you need to add 'Accept' as well as 'Authorization' in Access-Control-Allow-Headers

Also ensure GET is allowed in Access-Control-Allow-Methods

That's what I'd infer from the response your browser gave

On 19/08/2015 18:22, Fadi Abdin wrote:
> The authorization header seems got cut off .. here is it attached
>
> On Wed, Aug 19, 2015 at 1:20 PM, Fadi Abdin <fadiabdeen at gmail.com
> <mailto:fadiabdeen at gmail.com>> wrote:
>
>     Hey Marc,
>
>     Still no luck :( , i just got a fresh setup :
>
>     XMLHttpRequest cannot load
>     http://localhost:8080/apiman-gateway/express/testcors/1.0. No
>     'Access-Control-Allow-Origin' header is present on the requested
>     resource. Origin 'http://fadiabdeen.github.io' is therefore not
>     allowed access. The response had HTTP status code 403.
>
>     Here is  snapshots .. is there anything you see wrong ?
>
>
>
>
>
>          1.
>             Remote Address:
>             127.0.0.1:8080 <http://127.0.0.1:8080>
>          2.
>             Request URL:
>             http://localhost:8080/apiman-gateway/express/testcors/1.0
>          3.
>             Request Method:
>             OPTIONS
>          4.
>             Status Code:
>             403 Forbidden
>      1. Response Headersview source
>          1.
>             Access-Control-Max-Age:
>             0
>          2.
>             Connection:
>             keep-alive
>          3.
>             Content-Length:
>             149
>          4.
>             Content-Type:
>             application/json
>          5.
>             Date:
>             Wed, 19 Aug 2015 17:15:34 GMT
>          6.
>             Server:
>             WildFly/8
>          7.
>             X-Policy-Failure-Code:
>             400
>          8.
>             X-Policy-Failure-Message:
>             CORS: Requested header not allowed
>          9.
>             X-Policy-Failure-Type:
>             Authorization
>         10.
>             X-Powered-By:
>             Undertow/1
>      2. Request Headersview source
>          1.
>             Accept:
>             */*
>          2.
>             Accept-Encoding:
>             gzip, deflate, sdch
>          3.
>             Accept-Language:
>             en-US,en;q=0.8,ar;q=0.6
>          4.
>             Access-Control-Request-Headers:
>             accept, authorization
>          5.
>             Access-Control-Request-Method:
>             GET
>          6.
>             Connection:
>             keep-alive
>          7.
>             Host:
>             localhost:8080
>          8.
>             Origin:
>             http://fadiabdeen.github.io
>          9.
>             Referer:
>             http://fadiabdeen.github.io/keycloak-oauth/public_html/?code=P9o9yTC1ZiZQvlefHCt-nvRJ-4f72h8iaDgkSLN00aM.66a570dd-0c5d-4862-862a-d26106280de7
>         10.
>             User-Agent:
>             Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
>             AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155
>             Safari/537.36
>
>     Name
>
>
>
>
>     refresh
>     1.0
>
>     ?
>
>
>
>
>
>
>     On Wed, Aug 19, 2015 at 12:45 PM, Marc Savy <marc.savy at redhat.com
>     <mailto:marc.savy at redhat.com>> wrote:
>
>         In many cases people are using non-browser applications (e.g.
>         mobile, B2B, Java app...) which don't use CORS, so I don't think
>         they are necessarily concomitant in all circumstances.
>
>         Certainly makes sense to document things if people are unaware.
>
>         On 19/08/2015 17:36, Fadi Abdin wrote:
>
>             I think there is no need to relay on the API for the cors
>             since it can
>             be handled in the APIMan , but maybe something need to be
>             indicated that
>             the CORS Plugin must be installed and setup . at least in
>             the UI , and
>             ideally get installed with the Oauth plugin (keycloak) if
>             its not there.
>
>
>
>             On Wed, Aug 19, 2015 at 11:58 AM, Marc Savy
>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>>
>             wrote:
>
>                  I agree - I don't see any compelling reason to add that
>             kind of
>                  complexity for that case. I'm willing to be convinced,
>             though.
>
>                  On 19/08/2015 16:55, Eric Wittmann wrote:
>                   > That is exactly what I was getting at.  If you have
>             apiman performing
>                   > authentication, then apiman MUST ALSO perform CORS
>             for you.
>                  Specifically
>                   > for the reason you say:  we don't want to skip
>             authentication for
>                   > OPTIONS requests.
>                   >
>                   > That said, we *could* add another option to all the
>             authentication
>                   > policies, allowing auth to be skipped for specific
>             VERBs.  That
>                  could be
>                   > a reasonable feature.  I don't think I'm in favor of
>             it though.
>                   >
>                   > Instead, CORS functionality should be moved out of
>             the back-end
>                  system
>                   > and handled in apiman.
>                   >
>                   > -Eric
>                   >
>                   > On 8/19/2015 11:23 AM, Marc Savy wrote:
>                   > > I think case being suggested here is slightly
>             different -
>                   > >
>                   > > This is one where someone has selected an Auth
>             policy on the
>                  gateway,
>                   > > but *not* a CORS policy - instead their back-end
>             service
>                  supports CORS
>                   > > and they want the service to handle the preflight
>             request directly.
>                   > > Should we pipeline the CORS preflight request
>             through to the
>                  backend in
>                   > > that case (i.e. bypass auth)? I'd say no, probably.
>                   > >
>                   > > Perhaps that's what you were getting at already!
>                   > >
>                   > > On 19/08/2015 14:16, Eric Wittmann wrote:
>                   > >> I think that if apiman is being asked to do
>             Authentication
>                  *and* CORS is
>                   > >> required by the client, then apiman will have to
>             do both.
>                   > >>
>                   > >> I think that's desirable anyway - it allows the
>             back end service
>                   > >> implementation to not worry about supporting
>             CORS.  It's a
>                  win-win.
>                   > >>
>                   > >> -Eric
>                   > >>
>                   > >> On 8/19/2015 9:09 AM, Marc Savy wrote:
>                   > >> > What you're doing will always require a CORS
>             preflight
>                  request (due to
>                   > >> > the non-simple headers), and I'm not sure it
>             makes sense for
>                  us as an
>                   > >> > API gateway to funnel through CORS Preflight
>             requests to the
>                  service
>                   > >> > by default. It complicates things when you
>             start thinking about
>                   > >> > metering, security, etc.
>                   > >> >
>                   > >> > Eric, what do you think?
>                   > >> >
>                   > >> > On 19/08/2015 14:02, Fadi Abdin wrote:
>                   > >> >> So what it seems like is that we have to use
>             CORS Policy
>                  and add it
>                   > >> >> before the Keycloak authentication policy in
>             order for my
>                   > >> preflight to
>                   > >> >> pass .. thats the part i was missing
>             completely . i'm not
>                  sure if its
>                   > >> >> should be considered a bug or flexibility to
>             do what we
>                  want .. But
>                   > >> >> thanks for the explaination Marc.
>                   > >> >>
>                   > >> >> Anyway .. i'm still having a problem with CORS
>             Policy,
>                  probably I
>                   > >> just
>                   > >> >> dont have the latest code. i added some
>             details to the JIRA
>                  ticket
>                   > >> >>
>                   > >> >> On Wed, Aug 19, 2015 at 5:53 AM, Marc Savy
>                  <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>> wrote:
>                   > >> >>
>                   > >> >>      I replicated your set up as far as I
>             could, and I couldn't
>                   > >> >> replicate
>                   > >> >>      your issue (perhaps your CORS setup is
>             wrong?). Please
>                  see the
>                   > >> JIRA
>                   > >> >>      comments and screenshots -
>                   > >> >> https://issues.jboss.org/browse/APIMAN-516
>                   > >> >>
>                   > >> >>      Either way, I also fixed a bug unrelated
>             to your
>                  problem, so
>                   > >> please
>                   > >> >>      re-build the plugins before trying again :-).
>                   > >> >>
>                   > >> >>      On 18/08/2015 19:25, Fadi Abdin wrote:
>                   > >> >>
>                   > >> >>          It did not work .
>                   > >> >>
>                   > >> >>          I setup everything they way you told
>             me Marc and i'm
>                   > >> testing it
>                   > >> >>          on my
>                   > >> >>          local.
>                   > >> >>          It seems its sending that preflight
>             OPTIONS and
>                  coming back
>                   > >> >> with
>                   > >> >>          401 still
>                   > >> >>
>                   > >> >>          On Tue, Aug 18, 2015 at 10:48 AM,
>             Fadi Abdin
>                   > >> >>          <fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>
>                  <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>> <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>
>                  <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>>>
>                   > >> >>          <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>
>                  <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>> <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>
>                  <mailto:fadiabdeen at gmail.com
>             <mailto:fadiabdeen at gmail.com>>>>>
>                   > >> >> wrote:
>                   > >> >>
>                   > >> >>               I'm still working on it :( .. i
>             had to give
>                  the network
>                   > >> >>          guys few ip
>                   > >> >>               addresses to whitelist so i can
>             mvn install
>                  .. ...
>                   > >> almost
>                   > >> >>          there.
>                   > >> >>
>                   > >> >>               On Tue, Aug 18, 2015 at 9:46 AM,
>             Marc Savy
>                   > >> >>          <marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>
>                   > >> >>               <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>> wrote:
>                   > >> >>
>                   > >> >>                   My pleasure! Did it work?
>                   > >> >>
>                   > >> >>                   On 17/08/2015 16:38, Fadi
>             Abdin wrote:
>                   > >> >>
>                   > >> >>                       cool .. you're the man ;)
>                   > >> >>
>                   > >> >>
>                   > >> >>                       On Mon, Aug 17, 2015 at
>             11:37 AM,
>                  Marc Savy
>                   > >> >>                       <marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>
>                   > >> >>
>               <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>>>
>                   > >> >>                       wrote:
>                   > >> >>
>                   > >> >>                            I'm actually
>             testing the fix
>                  right now. It
>                   > >> >>          will land
>                   > >> >>                       both on the 1.2.x
>                   > >> >>                            branch and the
>             1.1.x branch
>                  shortly. You
>                   > >> >>          should be able
>                   > >> >>                       to test it out
>                   > >> >>                            in a short while:
>             I'll send you
>                  an email
>                   > >> >> when it's
>                   > >> >>                       available.
>                   > >> >>
>                   > >> >>                            On 17/08/2015
>             16:23, Fadi Abdin
>                  wrote:
>                   > >> >>
>                   > >> >>                                Thank you Marc,
>                   > >> >>                                Is there a work
>             around that
>                  you can
>                   > >> >> think of ?
>                   > >> >>                                I'm doing it
>             with angularjs
>                  , very
>                   > >> >> simple
>                   > >> >>
>                   > >> >>                                $http({method:
>             'GET', url:
>                   > >> >>
>               'http://server/apiman-gateway/service',
>                   > >> >>                                headers: {
>                   > >> >>
>             'Authorization': 'Bearer
>                   > >> >> XXXXXXXXXXXXX'}
>                   > >> >>                                });
>                   > >> >>
>                   > >> >>                                I assume you
>             will fix it in
>                  the new
>                   > >> >>          version , right?
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>                                On Mon, Aug 17,
>             2015 at
>                  10:52 AM, Marc
>                   > >> >> Savy
>                   > >> >>
>             <marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>
>                   > >> >>
>               <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>> <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>>
>                   > >> >>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>
>                   > >> >>
>               <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>
>             <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>
>                   > >> >>
>               <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com <mailto:marc.savy at redhat.com>>
>                   > >> >>          <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>
>                  <mailto:marc.savy at redhat.com
>             <mailto:marc.savy at redhat.com>>>>>>> wrote:
>                   > >> >>
>                   > >> >>                                     Hi,
>                   > >> >>
>                   > >> >>                                     This is
>             related to the
>                  JIRA I
>                   > >> linked
>                   > >> >>          you to
>                   > >> >>
>                   > >> >>
>             (https://issues.jboss.org/browse/APIMAN-516).
>                   > >> >>                       Because of
>                   > >> >>                                the way the
>                   > >> >>                                     policy
>             chain currently
>                  works the
>                   > >> >>          behaviour of
>                   > >> >>                       CORS is
>                   > >> >>                                invalid in a
>                   > >> >>                                     few very
>             specific cases
>                  (e.g.
>                   > >> when
>                   > >> >>          you stack
>                   > >> >>                       it with an auth
>                   > >> >>                                     policy).
>             I'll let you
>                  know when
>                   > >> it's
>                   > >> >>          fixed.
>                   > >> >>
>                   > >> >>                                     Regards,
>                   > >> >>                                     Marc
>                   > >> >>
>                   > >> >>                                     On
>             17/08/2015 15:44,
>                  Fadi Abdin
>                   > >> >> wrote:
>                   > >> >>
>                   > >> >>                                         I have
>             a problem in
>                  calling a
>                   > >> >>          service in
>                   > >> >>                       apiman-gateway
>                   > >> >>                                with the
>                   > >> >>
>               Authorization: Bearer
>                   > >> <token> in
>                   > >> >>          the header.
>                   > >> >>
>                   > >> >>                                         It
>             seems to
>                  preflight OPTIONS
>                   > >> >> and
>                   > >> >>          return
>                   > >> >>
>                   > >> >>                                           1.
>                   > >> >>
>                   > >> X-Policy-Failure-Message:
>                   > >> >>
>             OAuth2
>                  'Authorization'
>                   > >> >> header or
>                   > >> >>                       'access_token' query
>                   > >> >>
>               parameter must
>                   > >> >>
>             be provided.
>                   > >> >>
>                   > >> >>                                         I am
>             sending the
>                  bearer token
>                   > >> >>          with the
>                   > >> >>                       request and i
>                   > >> >>                                make sure
>                   > >> >>                                         in the
>                   > >> >>
>               preflight its sent
>                  in the
>                   > >> >> request.
>                   > >> >>
>                   > >> >>                                           1.
>                   > >> >>
>                   > >> >> Access-Control-Request-Headers:
>                   > >> >>
>             accept,
>                  authorization
>                   > >> >>
>                   > >> >>                                         Does
>             anyone know if
>                  there Is
>                   > >> >>          something i'm
>                   > >> >>                       missing ?
>                   > >> >>                                do i need
>                   > >> >>                                         to get
>                   > >> >>
>               authorization
>                  enabled or
>                   > >> added
>                   > >> >>          anywhere ?
>                   > >> >>                       as a side
>                   > >> >>                                note i have
>                   > >> >>                                         below in
>                   > >> >>                                         my api
>             as well:
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >> response.setHeader("Access-Control-Allow-Headers",
>                   > >> >>                                "Authorization");
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> _______________________________________________
>                   > >> >>
>               Apiman-user mailing
>                  list
>                   > >> >> Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >> <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>                   > >> >>
>               <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>>
>                   > >> >>
>               <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>                   > >> >>
>               <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>>>
>                   > >> >>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>                   > >> >>
>               <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>>
>                   > >> >>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>
>                   > >> >>
>               <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >>          <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>                  <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>>>>>
>                   > >> >>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >>
>                   > >> >
>                   > >> > _______________________________________________
>                   > >> > Apiman-user mailing list
>                   > >> > Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>                   > >> >
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>                   > >> >
>                   > >
>
>                  _______________________________________________
>                  Apiman-user mailing list
>             Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>
>             <mailto:Apiman-user at lists.jboss.org
>             <mailto:Apiman-user at lists.jboss.org>>
>             https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
>


From eric.wittmann at redhat.com  Wed Aug 19 14:16:02 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 19 Aug 2015 14:16:02 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0Se9eT_AUTpz3-z35Gc4+knQ2S62s0+0ikbQS8+JtQj0g@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D1FFAD.3000201@redhat.com>
	<CABXXV0SktviVhkeCYkD2EGbJaW5gjK0BxeSWm-9+xQNFPDiugw@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com> <55D4A6FA.1020109@redhat.com>
	<55D4A7BC.2060103@redhat.com>
	<CABXXV0Q6oLsd=zFFMz+EbRyG1f6V+Nf0fztTUZLOyZSJOwOfhw@mail.gmail.com>
	<55D4B2AC.5010508@redhat.com>
	<CABXXV0SL=4bcH-yss0kTRge+Fxc-hd3jNtZ5BkZcU2-FGBTo_g@mail.gmail.com>
	<CABXXV0S5jfpRdLmkM-nijf6FyHH_L9_H7V+v=Z2MNUhrVmyZPw@mail.gmail.com>
	<55D4BC13.90305@redhat.com>
	<CABXXV0Se9eT_AUTpz3-z35Gc4+knQ2S62s0+0ikbQS8+JtQj0g@mail.gmail.com>
Message-ID: <55D4C7E2.7050004@redhat.com>

What database are you using?  The default h2 database?  If you're going 
into production with apiman I would not recommend using h2.  I'm 
currently working on a "apiman in production" guide that should be 
available this week.

Ultimately it's likely going to be rather challenging to migrate 
existing data from older versions to newer ones until we support such a 
feature directly in apiman.

Also note - version 1.1.7.Final should get released next week I think - 
so you may be able to wait for that rather than build everything 
yourself from scratch.

-Eric

On 8/19/2015 2:05 PM, Fadi Abdin wrote:
> Yup , that was it .. Thanks for your help Marc  ...  ..
>
> I think i'm good now.  But i still need an advice.
>
> I need to get everything to work on our DEV and QA environments and
> since the fix is on 1.1.7-SNAPSHOT , i will need to do the same on the
> environments. and then later i need to upgrade to the new version.
>
> Now, the servers got 1.1.3-Final, and everything configured .
>
> What would you do ? its a lot of re-work since there is no import export
> , and also a lot of work for the developers if they going to change
> their code to update their keys and service endpoints.
>
>

From eric.wittmann at redhat.com  Wed Aug 19 14:24:28 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 19 Aug 2015 14:24:28 -0400
Subject: [Apiman-user] CORS
In-Reply-To: <CABXXV0TyW5FgTw5BPDC3H6F6QwG2qnx51EcWGhiRJBwLzYCXLg@mail.gmail.com>
References: <CABXXV0Td-VAU02VusJQi7a7CLGEgTcQ6kxpXDCGjC9DaqFp9BQ@mail.gmail.com>
	<55D33750.6020701@redhat.com>
	<CABXXV0SfefZ2VvsyxS4uDTUJfQU3jmSbna56yZJuB67uBgDnoQ@mail.gmail.com>
	<CABXXV0S831TFEz23GdH-ab2dgtG+Brsa0HQXi3U+h5dUzQ83oA@mail.gmail.com>
	<55D45201.9060907@redhat.com>
	<CABXXV0QzgvKDbUn9bjoRjeeKw973UFmspanMimVDWnauuViF7Q@mail.gmail.com>
	<55D48025.2020100@redhat.com> <55D481C7.1040403@redhat.com>
	<55D49F7A.9050300@redhat.com> <55D4A6FA.1020109@redhat.com>
	<55D4A7BC.2060103@redhat.com>
	<CABXXV0Q6oLsd=zFFMz+EbRyG1f6V+Nf0fztTUZLOyZSJOwOfhw@mail.gmail.com>
	<55D4B2AC.5010508@redhat.com>
	<CABXXV0SL=4bcH-yss0kTRge+Fxc-hd3jNtZ5BkZcU2-FGBTo_g@mail.gmail.com>
	<CABXXV0S5jfpRdLmkM-nijf6FyHH_L9_H7V+v=Z2MNUhrVmyZPw@mail.gmail.com>
	<55D4BC13.90305@redhat.com>
	<CABXXV0Se9eT_AUTpz3-z35Gc4+knQ2S62s0+0ikbQS8+JtQj0g@mail.gmail.com>
	<55D4C78C.4040709@redhat.com>
	<CABXXV0TyW5FgTw5BPDC3H6F6QwG2qnx51EcWGhiRJBwLzYCXLg@mail.gmail.com>
Message-ID: <55D4C9DC.3040401@redhat.com>

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

On 8/19/2015 2:19 PM, Fadi Abdin wrote:
> Yes, i'm using just the defaults.
> I wont be able to wait .. I'm getting a lot of pressure to have
> something stable asap.

From fadiabdeen at gmail.com  Thu Aug 20 11:08:34 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 20 Aug 2015 11:08:34 -0400
Subject: [Apiman-user] Plugins
Message-ID: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>

I have setup the DEV server with 1.1.7-SNAPSHOT.  but for some reason , i
can not install plugins on apimanui .

Before mvn clean install , i cleaned up my .m2 folder then built the apiman
and the apiman-plugns , then got everything configured and started it ,
everything seems to be working fine but when installing the plugins i get
404 .. here are snapshots
Any idea what should i do ??

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150820/480efad6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin2.PNG
Type: image/png
Size: 20480 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20150820/480efad6/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin1.PNG
Type: image/png
Size: 7718 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20150820/480efad6/attachment-0003.png 

From marc.savy at redhat.com  Thu Aug 20 11:30:25 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 20 Aug 2015 16:30:25 +0100
Subject: [Apiman-user] Plugins
In-Reply-To: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
Message-ID: <55D5F291.30507@redhat.com>

Hi Fadi,

1 - Which dev server are you talking about? How did you start it up, etc.
2- Did you mvn install the plugins into the .m2 repo of the machine you're running that server onto?

Regards,
Marc

On 20/08/2015 16:08, Fadi Abdin wrote:
> I have setup the DEV server with 1.1.7-SNAPSHOT.  but for some reason ,
> i can not install plugins on apimanui .
>
> Before mvn clean install , i cleaned up my .m2 folder then built the
> apiman and the apiman-plugns , then got everything configured and
> started it , everything seems to be working fine but when installing the
> plugins i get 404 .. here are snapshots
> Any idea what should i do ??
>
> ?
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Thu Aug 20 12:05:14 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 20 Aug 2015 12:05:14 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <55D5F291.30507@redhat.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com>
Message-ID: <55D5FABA.2020907@redhat.com>

If it helps, I just deployed version 1.1.7-SNAPSHOT versions of all our 
plugins into JBoss Nexus.  This should allow you to install them even if 
they aren't in your .m2 directory.

By default, apiman should be configured to pull plugins from JBoss Nexus.

Let me know if that works.

-eric

On 8/20/2015 11:30 AM, Marc Savy wrote:
> Hi Fadi,
>
> 1 - Which dev server are you talking about? How did you start it up, etc.
> 2- Did you mvn install the plugins into the .m2 repo of the machine you're running that server onto?
>
> Regards,
> Marc
>
> On 20/08/2015 16:08, Fadi Abdin wrote:
>> I have setup the DEV server with 1.1.7-SNAPSHOT.  but for some reason ,
>> i can not install plugins on apimanui .
>>
>> Before mvn clean install , i cleaned up my .m2 folder then built the
>> apiman and the apiman-plugns , then got everything configured and
>> started it , everything seems to be working fine but when installing the
>> plugins i get 404 .. here are snapshots
>> Any idea what should i do ??
>>
>> ?
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From fadiabdeen at gmail.com  Thu Aug 20 12:36:19 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 20 Aug 2015 12:36:19 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <55D5FABA.2020907@redhat.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
Message-ID: <CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>

I think i'm an idiot :( ... i was doing mvn install and clearning .m2 for
my user and running as root because i'm using port 80 and it requires root
... i just wasted few hours.

That definitely helps Eric i dont have to worry about users ..

Thank you both :) .. I keep bugging you both , but i'm hoping to get one
server up and stable for the other developers today ..


On Thu, Aug 20, 2015 at 12:05 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> If it helps, I just deployed version 1.1.7-SNAPSHOT versions of all our
> plugins into JBoss Nexus.  This should allow you to install them even if
> they aren't in your .m2 directory.
>
> By default, apiman should be configured to pull plugins from JBoss Nexus.
>
> Let me know if that works.
>
> -eric
>
>
> On 8/20/2015 11:30 AM, Marc Savy wrote:
>
>> Hi Fadi,
>>
>> 1 - Which dev server are you talking about? How did you start it up, etc.
>> 2- Did you mvn install the plugins into the .m2 repo of the machine
>> you're running that server onto?
>>
>> Regards,
>> Marc
>>
>> On 20/08/2015 16:08, Fadi Abdin wrote:
>>
>>> I have setup the DEV server with 1.1.7-SNAPSHOT.  but for some reason ,
>>> i can not install plugins on apimanui .
>>>
>>> Before mvn clean install , i cleaned up my .m2 folder then built the
>>> apiman and the apiman-plugns , then got everything configured and
>>> started it , everything seems to be working fine but when installing the
>>> plugins i get 404 .. here are snapshots
>>> Any idea what should i do ??
>>>
>>> ?
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>> _______________________________________________
>> 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/20150820/3f1b352c/attachment.html 

From fadiabdeen at gmail.com  Thu Aug 20 14:22:57 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 20 Aug 2015 14:22:57 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
	<CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
Message-ID: <CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>

I think i'm good now .. I was able to make a test service and passes

but i think i found bug ..  If i created a plan and set it up with same
policies i setup directly into the service with cors and keycloak , the
service that with the plan by passes keycloak and let me in even with the
browser directly . but the service setup with policies directly inside it
displays "OAuth2 'Authorization' header or 'access_token' query parameter
must be provided." .. which is correct .



On Thu, Aug 20, 2015 at 12:36 PM, Fadi Abdin <fadiabdeen at gmail.com> wrote:

> I think i'm an idiot :( ... i was doing mvn install and clearning .m2 for
> my user and running as root because i'm using port 80 and it requires root
> ... i just wasted few hours.
>
> That definitely helps Eric i dont have to worry about users ..
>
> Thank you both :) .. I keep bugging you both , but i'm hoping to get one
> server up and stable for the other developers today ..
>
>
> On Thu, Aug 20, 2015 at 12:05 PM, Eric Wittmann <eric.wittmann at redhat.com>
> wrote:
>
>> If it helps, I just deployed version 1.1.7-SNAPSHOT versions of all our
>> plugins into JBoss Nexus.  This should allow you to install them even if
>> they aren't in your .m2 directory.
>>
>> By default, apiman should be configured to pull plugins from JBoss Nexus.
>>
>> Let me know if that works.
>>
>> -eric
>>
>>
>> On 8/20/2015 11:30 AM, Marc Savy wrote:
>>
>>> Hi Fadi,
>>>
>>> 1 - Which dev server are you talking about? How did you start it up, etc.
>>> 2- Did you mvn install the plugins into the .m2 repo of the machine
>>> you're running that server onto?
>>>
>>> Regards,
>>> Marc
>>>
>>> On 20/08/2015 16:08, Fadi Abdin wrote:
>>>
>>>> I have setup the DEV server with 1.1.7-SNAPSHOT.  but for some reason ,
>>>> i can not install plugins on apimanui .
>>>>
>>>> Before mvn clean install , i cleaned up my .m2 folder then built the
>>>> apiman and the apiman-plugns , then got everything configured and
>>>> started it , everything seems to be working fine but when installing the
>>>> plugins i get 404 .. here are snapshots
>>>> Any idea what should i do ??
>>>>
>>>> ?
>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>>>
>>> _______________________________________________
>>> 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/20150820/f8cdc650/attachment.html 

From eric.wittmann at redhat.com  Thu Aug 20 15:21:18 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 20 Aug 2015 15:21:18 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
	<CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
	<CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
Message-ID: <55D628AE.7030405@redhat.com>

Have you marked the Service as Public by any chance?  You can find that 
setting on the service UI's "Plans" tab.

To make sure you really are using the plan you should *not* make your 
service public - that way you can't accidentally bypass your plan(s).

Note: once you start using plans, and if you do *not* have the service 
set to public, then you will not be able to invoke the service without 
an API Key.

-Eric

On 8/20/2015 2:22 PM, Fadi Abdin wrote:
> I think i'm good now .. I was able to make a test service and passes
>
> but i think i found bug ..  If i created a plan and set it up with same
> policies i setup directly into the service with cors and keycloak , the
> service that with the plan by passes keycloak and let me in even with
> the browser directly . but the service setup with policies directly
> inside it displays "OAuth2 'Authorization' header or 'access_token'
> query parameter must be provided." .. which is correct .

From eric.wittmann at redhat.com  Thu Aug 20 15:34:54 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 20 Aug 2015 15:34:54 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
	<CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
	<CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
Message-ID: <55D62BDE.4010101@redhat.com>

Also I should point out that you can only use plans if you also create 
at least one application (so that you can create a contract between the 
application and the service).  Plans don't make sense without an 
application, because without an API Key we won't know which plan is in 
use for a particular request.

-Eric

On 8/20/2015 2:22 PM, Fadi Abdin wrote:
> I think i'm good now .. I was able to make a test service and passes
>
> but i think i found bug ..  If i created a plan and set it up with same
> policies i setup directly into the service with cors and keycloak , the
> service that with the plan by passes keycloak and let me in even with
> the browser directly . but the service setup with policies directly
> inside it displays "OAuth2 'Authorization' header or 'access_token'
> query parameter must be provided." .. which is correct .

From fadiabdeen at gmail.com  Thu Aug 20 15:53:17 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 20 Aug 2015 15:53:17 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <55D62BDE.4010101@redhat.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
	<CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
	<CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
	<55D62BDE.4010101@redhat.com>
Message-ID: <CABXXV0To22PwwtcP=A8BCpEqWfbwSAFYeFT9ZGFtJPP=gwp7cA@mail.gmail.com>

I got it . then maybe this is not something i want to do now.

The only reason i was thinking about using plans , is because i have
multiple services and i dont want to setup policies for each one of them .
If i remember correctly, If i setup an application then the URL will change
, which i dont need to.

I only want services to be secured with the same set of policies. any
thoughts ?


On Thu, Aug 20, 2015 at 3:34 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Also I should point out that you can only use plans if you also create at
> least one application (so that you can create a contract between the
> application and the service).  Plans don't make sense without an
> application, because without an API Key we won't know which plan is in use
> for a particular request.
>
> -Eric
>
>
> On 8/20/2015 2:22 PM, Fadi Abdin wrote:
>
>> I think i'm good now .. I was able to make a test service and passes
>>
>> but i think i found bug ..  If i created a plan and set it up with same
>> policies i setup directly into the service with cors and keycloak , the
>> service that with the plan by passes keycloak and let me in even with
>> the browser directly . but the service setup with policies directly
>> inside it displays "OAuth2 'Authorization' header or 'access_token'
>> query parameter must be provided." .. which is correct .
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150820/4e152889/attachment-0001.html 

From eric.wittmann at redhat.com  Thu Aug 20 16:00:41 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 20 Aug 2015 16:00:41 -0400
Subject: [Apiman-user] Plugins
In-Reply-To: <CABXXV0To22PwwtcP=A8BCpEqWfbwSAFYeFT9ZGFtJPP=gwp7cA@mail.gmail.com>
References: <CABXXV0QdBxRzPJoyF+reeeWdkRZW6zgmBJLJ9OcbiuQNjjJ8ZA@mail.gmail.com>
	<55D5F291.30507@redhat.com> <55D5FABA.2020907@redhat.com>
	<CABXXV0StoC9iN0cDXoDwpiRMfFz9LFg6Ru4MJLBPfsxQ839FzA@mail.gmail.com>
	<CABXXV0SWY4SSdC=j+dAXkYWO4zbqsCmRRTuJJBS+gM4TexS49g@mail.gmail.com>
	<55D62BDE.4010101@redhat.com>
	<CABXXV0To22PwwtcP=A8BCpEqWfbwSAFYeFT9ZGFtJPP=gwp7cA@mail.gmail.com>
Message-ID: <55D631E9.80403@redhat.com>

The URL doesn't necessarily change when you add applications into the 
mix, but the API Key will need to be sent with each request.  That *can* 
be done on the URL or it can be done by sending it in an HTTP request 
header.

If your services are going to be consumed by a limited set of internal 
clients, then applications may be something you want to consider.  It 
gives you more than just plans - you will have the ability to track 
which clients are using which services.  That can be helpful.

If that isn't desired, then there is unfortunately no way to apply a set 
of policies to a service - you would need to configure each public 
service independently.  :(

Perhaps a feature request?

-Eric

On 8/20/2015 3:53 PM, Fadi Abdin wrote:
> I got it . then maybe this is not something i want to do now.
>
> The only reason i was thinking about using plans , is because i have
> multiple services and i dont want to setup policies for each one of them .
> If i remember correctly, If i setup an application then the URL will
> change , which i dont need to.
>
> I only want services to be secured with the same set of policies. any
> thoughts ?

From eric.wittmann at redhat.com  Fri Aug 21 14:04:02 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 21 Aug 2015 14:04:02 -0400
Subject: [Apiman-user] Announce: Release 1.1.7.Final
Message-ID: <55D76812.5010406@redhat.com>

Hi everyone.

 From now on we're only going to be fixing bugs in the 1.1.x line of 
apiman.  To that end, a new release just went out today (1.1.7.Final):

   http://www.apiman.io/latest/

All feature work going forward will be put on the 1.2.x line.  How many 
more 1.1.x releases will there be?  Great question!  I guess that 
depends on how many bugs we find!  Get some eyeballs on there and let's 
shake them all out.

-Eric


From brooks.isoldi at traversed.com  Mon Aug 24 17:35:01 2015
From: brooks.isoldi at traversed.com (Brooks Isoldi)
Date: Mon, 24 Aug 2015 17:35:01 -0400
Subject: [Apiman-user] PKI Compatibility
Message-ID: <55DB8E05.2020102@traversed.com>

Hi all,

     Does APIMan have the ability to validate inbound HTTPS requests 
with custom signed certificates to consume a service via a PKI service?

     So...a network where all internal traffic is encrypted with SSL, 
signed via an internal PKI service.  The request to APIMan to consume 
the service would be via HTTPS and I am hoping APIMan can:

- Validate the request based on the certificate and PKI service
- Validate the request based on the rate limiting rules
- Consume the service or reject the request accordingly

     Thanks!


-- 
Brooks Isoldi, Software Developer

Traversed
7164 Columbia Gateway Drive, Suite 120A
Columbia, MD 21046

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150824/b0e93176/attachment.html 

From marc.savy at redhat.com  Tue Aug 25 05:57:08 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 25 Aug 2015 10:57:08 +0100
Subject: [Apiman-user] PKI Compatibility
In-Reply-To: <55DB8E05.2020102@traversed.com>
References: <55DB8E05.2020102@traversed.com>
Message-ID: <55DC3BF4.6090601@redhat.com>

Hi Brooks,

Do you just mean mutual auth between the client and apiman gateway? https://docs.jboss.org/author/display/WFLY8/Detailed+Configuration

Or perhaps also mutual auth between the gateway and the backend? http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/2015/06/16/mtls-mutual-auth.html

We don't currently support routing requests based upon the certificate (in lieu of an api key, for instance)

Regards,
Marc

On 24/08/2015 22:35, Brooks Isoldi wrote:
> Hi all,
>
>      Does APIMan have the ability to validate inbound HTTPS requests
> with custom signed certificates to consume a service via a PKI service?
>
>      So...a network where all internal traffic is encrypted with SSL,
> signed via an internal PKI service.  The request to APIMan to consume
> the service would be via HTTPS and I am hoping APIMan can:
>
> - Validate the request based on the certificate and PKI service
> - Validate the request based on the rate limiting rules
> - Consume the service or reject the request accordingly
>
>      Thanks!
>
>
> -- 
> Brooks Isoldi, Software Developer
>
> Traversed
> 7164 Columbia Gateway Drive, Suite 120A
> Columbia, MD 21046
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From rafaelcba at gmail.com  Tue Aug 25 17:42:08 2015
From: rafaelcba at gmail.com (Rafael Soares)
Date: Tue, 25 Aug 2015 18:42:08 -0300
Subject: [Apiman-user] Help with ApiMan oAuth2 plugin tutorial
Message-ID: <CAE2FsvWstdDhtgdUkoAAu2V1B9ZhBk6CjK3jkTwtBX7eaFBY3w@mail.gmail.com>

Hello all!

I'm trying to follow the tutorial for the oAuth2 plugin [1] but I had some
issues.
The authentication policy worked fine! After adding the second policy
(Authorization) I get the following response error

HTTP/1.1 500 Internal Server Error
Connection: keep-alive
Content-Length: 238
Content-Type: application/json
Date: Tue, 25 Aug 2015 21:12:31 GMT
Server: WildFly/8
X-Policy-Failure-Code: 10010
X-Policy-Failure-Message: No roles have been extracted during
authentication.  Make sure the authorization policy comes *after* a
compatible authentication policy in your configuration.
X-Policy-Failure-Type: Other
X-Powered-By: Undertow/1

{
    "failureCode": 10010,
    "headers": {},
    "message": *"No roles have been extracted during authentication.  Make
sure the authorization policy comes *after* a compatible authentication
policy in your configuration.*",
    "responseCode": 0,
    "type": "Other"
}


but my JWT access_token appears to be right. I mean, I can see the roles in
it. See my access_toke decoded:

{
  "preferred_username": "rincewind",


  "name": "",


  "resource_access": {


    "account": {


      "roles": [


        "manage-account",


        "view-profile"
      ]


    }


  },


  "*realm_access": {

        *
*    "roles": [

       *
*      "echomeister"*
*    ]

        *
*  }*,


  "allowed-origins": [],


  "client_session": "b25536e6-4331-46fd-afe1-b0adf766b533",


  "session_state": "213e75e1-bf8b-4f0c-808e-683fb3a4c1de",


  "jti": "43c59d9a-b659-4708-a1da-968ea23004d7",


  "exp": 1440536956,


  "nbf": 0,


  "iat": 1440536656,


  "iss": "http://127.0.0.1:8080/auth/realms/stottie",


  "aud": "apiman",


  "sub": "de4af322-85b2-4dbe-8d53-6a2ee29e4080",


  "azp": "apiman"
}


As you can see the "*echomeister*" realm_role is there...

What this response message means?

[1]
http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html
________________________
Rafael Torres Coelho Soares
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150825/0e061bef/attachment.html 

From rafaelcba at gmail.com  Tue Aug 25 21:14:42 2015
From: rafaelcba at gmail.com (Rafael Soares)
Date: Tue, 25 Aug 2015 22:14:42 -0300
Subject: [Apiman-user] Help with ApiMan oAuth2 plugin tutorial
In-Reply-To: <CAE2FsvWstdDhtgdUkoAAu2V1B9ZhBk6CjK3jkTwtBX7eaFBY3w@mail.gmail.com>
References: <CAE2FsvWstdDhtgdUkoAAu2V1B9ZhBk6CjK3jkTwtBX7eaFBY3w@mail.gmail.com>
Message-ID: <CAE2FsvWwYRpqiUYRiOtFBzTf5Eu068DFgxO6Zz=ehF7yB-5x1A@mail.gmail.com>

Hi!

I found the problem. It was my mistake :-|

In the Keycloak OAuth Policy Configuration I forgot to set the property
'Forward Realm Roles?' to true...
I created a new version, changed the Policy configuration and now it's
working as expected.

Thanks :-)

________________________
Rafael Torres Coelho Soares

On Tue, Aug 25, 2015 at 6:42 PM, Rafael Soares <rafaelcba at gmail.com> wrote:

> Hello all!
>
> I'm trying to follow the tutorial for the oAuth2 plugin [1] but I had some
> issues.
> The authentication policy worked fine! After adding the second policy
> (Authorization) I get the following response error
>
> HTTP/1.1 500 Internal Server Error
> Connection: keep-alive
> Content-Length: 238
> Content-Type: application/json
> Date: Tue, 25 Aug 2015 21:12:31 GMT
> Server: WildFly/8
> X-Policy-Failure-Code: 10010
> X-Policy-Failure-Message: No roles have been extracted during
> authentication.  Make sure the authorization policy comes *after* a
> compatible authentication policy in your configuration.
> X-Policy-Failure-Type: Other
> X-Powered-By: Undertow/1
>
> {
>     "failureCode": 10010,
>     "headers": {},
>     "message": *"No roles have been extracted during authentication.
> Make sure the authorization policy comes *after* a compatible
> authentication policy in your configuration.*",
>     "responseCode": 0,
>     "type": "Other"
> }
>
>
> but my JWT access_token appears to be right. I mean, I can see the roles
> in it. See my access_toke decoded:
>
> {
>   "preferred_username": "rincewind",
>
>
>   "name": "",
>
>
>   "resource_access": {
>
>
>     "account": {
>
>
>       "roles": [
>
>
>         "manage-account",
>
>
>         "view-profile"
>       ]
>
>
>     }
>
>
>   },
>
>
>   "*realm_access": {
>
>           *
> *    "roles": [
>
>          *
> *      "echomeister"*
> *    ]
>
>         *
> *  }*,
>
>
>   "allowed-origins": [],
>
>
>   "client_session": "b25536e6-4331-46fd-afe1-b0adf766b533",
>
>
>   "session_state": "213e75e1-bf8b-4f0c-808e-683fb3a4c1de",
>
>
>   "jti": "43c59d9a-b659-4708-a1da-968ea23004d7",
>
>
>   "exp": 1440536956,
>
>
>   "nbf": 0,
>
>
>   "iat": 1440536656,
>
>
>   "iss": "http://127.0.0.1:8080/auth/realms/stottie",
>
>
>   "aud": "apiman",
>
>
>   "sub": "de4af322-85b2-4dbe-8d53-6a2ee29e4080",
>
>
>   "azp": "apiman"
> }
>
>
> As you can see the "*echomeister*" realm_role is there...
>
> What this response message means?
>
> [1]
> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html
> ________________________
> Rafael Torres Coelho Soares
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150825/a63dfc8d/attachment-0001.html 

From eric.wittmann at redhat.com  Wed Aug 26 08:45:30 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 26 Aug 2015 08:45:30 -0400 (EDT)
Subject: [Apiman-user] Help with ApiMan oAuth2 plugin tutorial
In-Reply-To: <CAE2FsvWwYRpqiUYRiOtFBzTf5Eu068DFgxO6Zz=ehF7yB-5x1A@mail.gmail.com>
References: <CAE2FsvWstdDhtgdUkoAAu2V1B9ZhBk6CjK3jkTwtBX7eaFBY3w@mail.gmail.com>
	<CAE2FsvWwYRpqiUYRiOtFBzTf5Eu068DFgxO6Zz=ehF7yB-5x1A@mail.gmail.com>
Message-ID: <571945090.9483751.1440593130085.JavaMail.zimbra@redhat.com>

Fantastic!

----- Original Message -----
From: "Rafael Soares" <rafaelcba at gmail.com>
To: apiman-user at lists.jboss.org
Sent: Tuesday, August 25, 2015 9:14:42 PM
Subject: Re: [Apiman-user] Help with ApiMan oAuth2 plugin tutorial

Hi! 

I found the problem. It was my mistake :-| 

In the Keycloak OAuth Policy Configuration I forgot to set the property 'Forward Realm Roles?' to true... 
I created a new version, changed the Policy configuration and now it's working as expected. 

Thanks :-) 

From fadiabdeen at gmail.com  Thu Aug 27 14:48:55 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 27 Aug 2015 14:48:55 -0400
Subject: [Apiman-user] HTTP Methods
Message-ID: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>

Hey Eric / Marc,

Everything going good so far with the CORS fix but guessing there is
something still, or maybe i'm doing something wrong ( it always happened to
me ).

I have setup my CORS Policy in API Man and included
"Access-Control-Allow-Methods" : "OPTIONS","GET","POST","DELETE",'PUT".

But i get a 403 and "CORS: Invalid preflight request; must use OPTIONS
verb." on ANY service that is not GET.

OPTIONS Header :


   1. Remote Address:
      172.26.209.66:443
      2. Request URL:

      https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
      3. Request Method:
      OPTIONS
      4. Status Code:
      200 OK
      1. Response Headersview source
      1. Access-Control-Allow-Headers:
      Accept, Authorization, Head
      2. Access-Control-Allow-Methods:
      OPTIONS, GET, POST, DELETE, PUT
      3. Access-Control-Allow-Origin:
      http://localhost:8383
      4. Access-Control-Max-Age:
      0
      5. Connection:
      keep-alive
      6. Date:
      Thu, 27 Aug 2015 18:44:39 GMT
      7. Server:
      WildFly/8
      8. Transfer-Encoding:
      chunked
      9. X-Powered-By:
      Undertow/1
      2. Request Headersview source
      1. Accept:
      */*
      2. Accept-Encoding:
      gzip, deflate, sdch
      3. Accept-Language:
      en-US,en;q=0.8,ar;q=0.6
      4. Access-Control-Request-Headers:
      accept, authorization
      5. Access-Control-Request-Method:
      POST
      6. Cache-Control:
      no-cache
      7. Connection:
      keep-alive
      8. Host:
      dev-internal-api.expdev.local
      9. Origin:
      http://localhost:8383
      10. Pragma:
      no-cache
      11. Referer:

      http://localhost:8383/keycloak-oauth/index.html?code=1SnLPvM2b4cuXeMp3w8s-3ETKBuI7hyPFy6mRs3hMy4.677e4cee-3dd7-4d19-9268-5045d171327





POST HEADER


   1. Remote Address:
         172.26.209.66:443
         2. Request URL:

         https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
         3. Request Method:
         POST
         4. Status Code:
         403 Forbidden
         1. Response Headersview source
         1. Access-Control-Allow-Origin:
         http://localhost:8383
         2. Connection:
         keep-alive
         3. Content-Length:
         195
         4. Content-Type:
         application/json
         5. Date:
         Thu, 27 Aug 2015 18:44:39 GMT
         6. Server:
         WildFly/8
         7. X-Policy-Failure-Code:
         400
         8. X-Policy-Failure-Message:
         CORS: Invalid preflight request; must use OPTIONS verb.
         9. X-Policy-Failure-Type:
         Authorization
         10. X-Powered-By:
         Undertow/1
         2. Request Headersview source
         1. Accept:
         application/json, text/plain, */*
         2. Accept-Encoding:
         gzip, deflate
         3. Accept-Language:
         en-US,en;q=0.8,ar;q=0.6
         4. Authorization:
         Bearer
         eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkYTI.................................qoQRgKQ
         5. Cache-Control:
         no-cache
         6. Connection:
         keep-alive
         7. Content-Length:
         0
         8. Host:
         dev-internal-api.expdev.local
         9. Origin:
         http://localhost:8383
         10. Pragma:
         no-cache
         11.
         12.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150827/2a8f5b9c/attachment-0001.html 

From eric.wittmann at redhat.com  Thu Aug 27 15:02:45 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 27 Aug 2015 15:02:45 -0400
Subject: [Apiman-user] HTTP Methods
In-Reply-To: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>
References: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>
Message-ID: <55DF5ED5.5070007@redhat.com>

Hi Fadi.

It's possible this is a bug in the CORS policy or a mis-configuration. 
Hopefully Marc can respond shortly.

One thing I'll say is that you *probably* don't need to include 
"OPTIONS" as one of the allowed CORS methods.

-Eric

On 8/27/2015 2:48 PM, Fadi Abdin wrote:
> Hey Eric / Marc,
>
> Everything going good so far with the CORS fix but guessing there is
> something still, or maybe i'm doing something wrong ( it always happened
> to me ).
>
> I have setup my CORS Policy in API Man and included
> "Access-Control-Allow-Methods" : "OPTIONS","GET","POST","DELETE",'PUT".
>
> But i get a 403 and "CORS: Invalid preflight request; must use OPTIONS
> verb." on ANY service that is not GET.
>
> OPTIONS Header :
>
>      1.
>         Remote Address:
>         172.26.209.66:443 <http://172.26.209.66:443>
>      2.
>         Request URL:
>         https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>      3.
>         Request Method:
>         OPTIONS
>      4.
>         Status Code:
>         200 OK
>  1. Response Headersview source
>      1.
>         Access-Control-Allow-Headers:
>         Accept, Authorization, Head
>      2.
>         Access-Control-Allow-Methods:
>         OPTIONS, GET, POST, DELETE, PUT
>      3.
>         Access-Control-Allow-Origin:
>         http://localhost:8383
>      4.
>         Access-Control-Max-Age:
>         0
>      5.
>         Connection:
>         keep-alive
>      6.
>         Date:
>         Thu, 27 Aug 2015 18:44:39 GMT
>      7.
>         Server:
>         WildFly/8
>      8.
>         Transfer-Encoding:
>         chunked
>      9.
>         X-Powered-By:
>         Undertow/1
>  2. Request Headersview source
>      1.
>         Accept:
>         */*
>      2.
>         Accept-Encoding:
>         gzip, deflate, sdch
>      3.
>         Accept-Language:
>         en-US,en;q=0.8,ar;q=0.6
>      4.
>         Access-Control-Request-Headers:
>         accept, authorization
>      5.
>         Access-Control-Request-Method:
>         POST
>      6.
>         Cache-Control:
>         no-cache
>      7.
>         Connection:
>         keep-alive
>      8.
>         Host:
>         dev-internal-api.expdev.local
>      9.
>         Origin:
>         http://localhost:8383
>     10.
>         Pragma:
>         no-cache
>     11.
>         Referer:
>         http://localhost:8383/keycloak-oauth/index.html?code=1SnLPvM2b4cuXeMp3w8s-3ETKBuI7hyPFy6mRs3hMy4.677e4cee-3dd7-4d19-9268-5045d171327
>
>
>
>
> POST HEADER
>
>          1.
>             Remote Address:
>             172.26.209.66:443 <http://172.26.209.66:443>
>          2.
>             Request URL:
>             https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>          3.
>             Request Method:
>             POST
>          4.
>             Status Code:
>             403 Forbidden
>      1. Response Headersview source
>          1.
>             Access-Control-Allow-Origin:
>             http://localhost:8383
>          2.
>             Connection:
>             keep-alive
>          3.
>             Content-Length:
>             195
>          4.
>             Content-Type:
>             application/json
>          5.
>             Date:
>             Thu, 27 Aug 2015 18:44:39 GMT
>          6.
>             Server:
>             WildFly/8
>          7.
>             X-Policy-Failure-Code:
>             400
>          8.
>             X-Policy-Failure-Message:
>             CORS: Invalid preflight request; must use OPTIONS verb.
>          9.
>             X-Policy-Failure-Type:
>             Authorization
>         10.
>             X-Powered-By:
>             Undertow/1
>      2. Request Headersview source
>          1.
>             Accept:
>             application/json, text/plain, */*
>          2.
>             Accept-Encoding:
>             gzip, deflate
>          3.
>             Accept-Language:
>             en-US,en;q=0.8,ar;q=0.6
>          4.
>             Authorization:
>             Bearer
>             eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkYTI.................................qoQRgKQ
>          5.
>             Cache-Control:
>             no-cache
>          6.
>             Connection:
>             keep-alive
>          7.
>             Content-Length:
>             0
>          8.
>             Host:
>             dev-internal-api.expdev.local
>          9.
>             Origin:
>             http://localhost:8383
>         10.
>             Pragma:
>             no-cache
>         11.
>
> 12.
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Fri Aug 28 05:53:05 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 28 Aug 2015 10:53:05 +0100
Subject: [Apiman-user] HTTP Methods
In-Reply-To: <55DF5ED5.5070007@redhat.com>
References: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>
	<55DF5ED5.5070007@redhat.com>
Message-ID: <55E02F81.6040902@redhat.com>

I think there may have been some overzealous error detection going on. Please try out the latest master/1.1.x.

On 27/08/2015 20:02, Eric Wittmann wrote:
> Hi Fadi.
>
> It's possible this is a bug in the CORS policy or a mis-configuration.
> Hopefully Marc can respond shortly.
>
> One thing I'll say is that you *probably* don't need to include
> "OPTIONS" as one of the allowed CORS methods.
>
> -Eric
>
> On 8/27/2015 2:48 PM, Fadi Abdin wrote:
> > Hey Eric / Marc,
> >
> > Everything going good so far with the CORS fix but guessing there is
> > something still, or maybe i'm doing something wrong ( it always happened
> > to me ).
> >
> > I have setup my CORS Policy in API Man and included
> > "Access-Control-Allow-Methods" : "OPTIONS","GET","POST","DELETE",'PUT".
> >
> > But i get a 403 and "CORS: Invalid preflight request; must use OPTIONS
> > verb." on ANY service that is not GET.
> >
> > OPTIONS Header :
> >
> >       1.
> >          Remote Address:
> >          172.26.209.66:443 <http://172.26.209.66:443>
> >       2.
> >          Request URL:
> >          https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
> >       3.
> >          Request Method:
> >          OPTIONS
> >       4.
> >          Status Code:
> >          200 OK
> >   1. Response Headersview source
> >       1.
> >          Access-Control-Allow-Headers:
> >          Accept, Authorization, Head
> >       2.
> >          Access-Control-Allow-Methods:
> >          OPTIONS, GET, POST, DELETE, PUT
> >       3.
> >          Access-Control-Allow-Origin:
> >          http://localhost:8383
> >       4.
> >          Access-Control-Max-Age:
> >          0
> >       5.
> >          Connection:
> >          keep-alive
> >       6.
> >          Date:
> >          Thu, 27 Aug 2015 18:44:39 GMT
> >       7.
> >          Server:
> >          WildFly/8
> >       8.
> >          Transfer-Encoding:
> >          chunked
> >       9.
> >          X-Powered-By:
> >          Undertow/1
> >   2. Request Headersview source
> >       1.
> >          Accept:
> >          */*
> >       2.
> >          Accept-Encoding:
> >          gzip, deflate, sdch
> >       3.
> >          Accept-Language:
> >          en-US,en;q=0.8,ar;q=0.6
> >       4.
> >          Access-Control-Request-Headers:
> >          accept, authorization
> >       5.
> >          Access-Control-Request-Method:
> >          POST
> >       6.
> >          Cache-Control:
> >          no-cache
> >       7.
> >          Connection:
> >          keep-alive
> >       8.
> >          Host:
> >          dev-internal-api.expdev.local
> >       9.
> >          Origin:
> >          http://localhost:8383
> >      10.
> >          Pragma:
> >          no-cache
> >      11.
> >          Referer:
> >          http://localhost:8383/keycloak-oauth/index.html?code=1SnLPvM2b4cuXeMp3w8s-3ETKBuI7hyPFy6mRs3hMy4.677e4cee-3dd7-4d19-9268-5045d171327
> >
> >
> >
> >
> > POST HEADER
> >
> >           1.
> >              Remote Address:
> >              172.26.209.66:443 <http://172.26.209.66:443>
> >           2.
> >              Request URL:
> >              https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
> >           3.
> >              Request Method:
> >              POST
> >           4.
> >              Status Code:
> >              403 Forbidden
> >       1. Response Headersview source
> >           1.
> >              Access-Control-Allow-Origin:
> >              http://localhost:8383
> >           2.
> >              Connection:
> >              keep-alive
> >           3.
> >              Content-Length:
> >              195
> >           4.
> >              Content-Type:
> >              application/json
> >           5.
> >              Date:
> >              Thu, 27 Aug 2015 18:44:39 GMT
> >           6.
> >              Server:
> >              WildFly/8
> >           7.
> >              X-Policy-Failure-Code:
> >              400
> >           8.
> >              X-Policy-Failure-Message:
> >              CORS: Invalid preflight request; must use OPTIONS verb.
> >           9.
> >              X-Policy-Failure-Type:
> >              Authorization
> >          10.
> >              X-Powered-By:
> >              Undertow/1
> >       2. Request Headersview source
> >           1.
> >              Accept:
> >              application/json, text/plain, */*
> >           2.
> >              Accept-Encoding:
> >              gzip, deflate
> >           3.
> >              Accept-Language:
> >              en-US,en;q=0.8,ar;q=0.6
> >           4.
> >              Authorization:
> >              Bearer
> >              eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkYTI.................................qoQRgKQ
> >           5.
> >              Cache-Control:
> >              no-cache
> >           6.
> >              Connection:
> >              keep-alive
> >           7.
> >              Content-Length:
> >              0
> >           8.
> >              Host:
> >              dev-internal-api.expdev.local
> >           9.
> >              Origin:
> >              http://localhost:8383
> >          10.
> >              Pragma:
> >              no-cache
> >          11.
> >
> > 12.
> >
> >
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From fadiabdeen at gmail.com  Fri Aug 28 08:40:57 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Fri, 28 Aug 2015 08:40:57 -0400
Subject: [Apiman-user] HTTP Methods
In-Reply-To: <55E02F81.6040902@redhat.com>
References: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>
	<55DF5ED5.5070007@redhat.com> <55E02F81.6040902@redhat.com>
Message-ID: <CABXXV0TOgNQAac1j9-MX3=+bHOzhD5KbBGFjDhS5VZx08A6wMQ@mail.gmail.com>

latest of cors-policy-plugin?

On Fri, Aug 28, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com> wrote:

> I think there may have been some overzealous error detection going on.
> Please try out the latest master/1.1.x.
>
>
> On 27/08/2015 20:02, Eric Wittmann wrote:
>
>> Hi Fadi.
>>
>> It's possible this is a bug in the CORS policy or a mis-configuration.
>> Hopefully Marc can respond shortly.
>>
>> One thing I'll say is that you *probably* don't need to include
>> "OPTIONS" as one of the allowed CORS methods.
>>
>> -Eric
>>
>> On 8/27/2015 2:48 PM, Fadi Abdin wrote:
>> > Hey Eric / Marc,
>> >
>> > Everything going good so far with the CORS fix but guessing there is
>> > something still, or maybe i'm doing something wrong ( it always happened
>> > to me ).
>> >
>> > I have setup my CORS Policy in API Man and included
>> > "Access-Control-Allow-Methods" : "OPTIONS","GET","POST","DELETE",'PUT".
>> >
>> > But i get a 403 and "CORS: Invalid preflight request; must use OPTIONS
>> > verb." on ANY service that is not GET.
>> >
>> > OPTIONS Header :
>> >
>> >       1.
>> >          Remote Address:
>> >          172.26.209.66:443 <http://172.26.209.66:443>
>> >       2.
>> >          Request URL:
>> >
>> https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>> >       3.
>> >          Request Method:
>> >          OPTIONS
>> >       4.
>> >          Status Code:
>> >          200 OK
>> >   1. Response Headersview source
>> >       1.
>> >          Access-Control-Allow-Headers:
>> >          Accept, Authorization, Head
>> >       2.
>> >          Access-Control-Allow-Methods:
>> >          OPTIONS, GET, POST, DELETE, PUT
>> >       3.
>> >          Access-Control-Allow-Origin:
>> >          http://localhost:8383
>> >       4.
>> >          Access-Control-Max-Age:
>> >          0
>> >       5.
>> >          Connection:
>> >          keep-alive
>> >       6.
>> >          Date:
>> >          Thu, 27 Aug 2015 18:44:39 GMT
>> >       7.
>> >          Server:
>> >          WildFly/8
>> >       8.
>> >          Transfer-Encoding:
>> >          chunked
>> >       9.
>> >          X-Powered-By:
>> >          Undertow/1
>> >   2. Request Headersview source
>> >       1.
>> >          Accept:
>> >          */*
>> >       2.
>> >          Accept-Encoding:
>> >          gzip, deflate, sdch
>> >       3.
>> >          Accept-Language:
>> >          en-US,en;q=0.8,ar;q=0.6
>> >       4.
>> >          Access-Control-Request-Headers:
>> >          accept, authorization
>> >       5.
>> >          Access-Control-Request-Method:
>> >          POST
>> >       6.
>> >          Cache-Control:
>> >          no-cache
>> >       7.
>> >          Connection:
>> >          keep-alive
>> >       8.
>> >          Host:
>> >          dev-internal-api.expdev.local
>> >       9.
>> >          Origin:
>> >          http://localhost:8383
>> >      10.
>> >          Pragma:
>> >          no-cache
>> >      11.
>> >          Referer:
>> >
>> http://localhost:8383/keycloak-oauth/index.html?code=1SnLPvM2b4cuXeMp3w8s-3ETKBuI7hyPFy6mRs3hMy4.677e4cee-3dd7-4d19-9268-5045d171327
>> >
>> >
>> >
>> >
>> > POST HEADER
>> >
>> >           1.
>> >              Remote Address:
>> >              172.26.209.66:443 <http://172.26.209.66:443>
>> >           2.
>> >              Request URL:
>> >
>> https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>> >           3.
>> >              Request Method:
>> >              POST
>> >           4.
>> >              Status Code:
>> >              403 Forbidden
>> >       1. Response Headersview source
>> >           1.
>> >              Access-Control-Allow-Origin:
>> >              http://localhost:8383
>> >           2.
>> >              Connection:
>> >              keep-alive
>> >           3.
>> >              Content-Length:
>> >              195
>> >           4.
>> >              Content-Type:
>> >              application/json
>> >           5.
>> >              Date:
>> >              Thu, 27 Aug 2015 18:44:39 GMT
>> >           6.
>> >              Server:
>> >              WildFly/8
>> >           7.
>> >              X-Policy-Failure-Code:
>> >              400
>> >           8.
>> >              X-Policy-Failure-Message:
>> >              CORS: Invalid preflight request; must use OPTIONS verb.
>> >           9.
>> >              X-Policy-Failure-Type:
>> >              Authorization
>> >          10.
>> >              X-Powered-By:
>> >              Undertow/1
>> >       2. Request Headersview source
>> >           1.
>> >              Accept:
>> >              application/json, text/plain, */*
>> >           2.
>> >              Accept-Encoding:
>> >              gzip, deflate
>> >           3.
>> >              Accept-Language:
>> >              en-US,en;q=0.8,ar;q=0.6
>> >           4.
>> >              Authorization:
>> >              Bearer
>> >
>> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkYTI.................................qoQRgKQ
>> >           5.
>> >              Cache-Control:
>> >              no-cache
>> >           6.
>> >              Connection:
>> >              keep-alive
>> >           7.
>> >              Content-Length:
>> >              0
>> >           8.
>> >              Host:
>> >              dev-internal-api.expdev.local
>> >           9.
>> >              Origin:
>> >              http://localhost:8383
>> >          10.
>> >              Pragma:
>> >              no-cache
>> >          11.
>> >
>> > 12.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>> _______________________________________________
>> 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/20150828/478927dd/attachment-0001.html 

From marc.savy at redhat.com  Fri Aug 28 08:42:25 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 28 Aug 2015 13:42:25 +0100
Subject: [Apiman-user] HTTP Methods
In-Reply-To: <CABXXV0TOgNQAac1j9-MX3=+bHOzhD5KbBGFjDhS5VZx08A6wMQ@mail.gmail.com>
References: <CABXXV0SbjsiuEzhtvMNahaQuWgcr6hR1b=gpa+K34UfdomfJ7Q@mail.gmail.com>
	<55DF5ED5.5070007@redhat.com> <55E02F81.6040902@redhat.com>
	<CABXXV0TOgNQAac1j9-MX3=+bHOzhD5KbBGFjDhS5VZx08A6wMQ@mail.gmail.com>
Message-ID: <55E05731.7090708@redhat.com>

Should be 'apiman-plugins-cors-policy' ; repo is 'apiman-plugins'

On 28/08/2015 13:40, Fadi Abdin wrote:
> latest of cors-policy-plugin?
>
> On Fri, Aug 28, 2015 at 5:53 AM, Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>> wrote:
>
>     I think there may have been some overzealous error detection going
>     on. Please try out the latest master/1.1.x.
>
>
>     On 27/08/2015 20:02, Eric Wittmann wrote:
>
>         Hi Fadi.
>
>         It's possible this is a bug in the CORS policy or a
>         mis-configuration.
>         Hopefully Marc can respond shortly.
>
>         One thing I'll say is that you *probably* don't need to include
>         "OPTIONS" as one of the allowed CORS methods.
>
>         -Eric
>
>         On 8/27/2015 2:48 PM, Fadi Abdin wrote:
>          > Hey Eric / Marc,
>          >
>          > Everything going good so far with the CORS fix but guessing
>         there is
>          > something still, or maybe i'm doing something wrong ( it
>         always happened
>          > to me ).
>          >
>          > I have setup my CORS Policy in API Man and included
>          > "Access-Control-Allow-Methods" :
>         "OPTIONS","GET","POST","DELETE",'PUT".
>          >
>          > But i get a 403 and "CORS: Invalid preflight request; must
>         use OPTIONS
>          > verb." on ANY service that is not GET.
>          >
>          > OPTIONS Header :
>          >
>          >       1.
>          >          Remote Address:
>          > 172.26.209.66:443 <http://172.26.209.66:443>
>         <http://172.26.209.66:443>
>          >       2.
>          >          Request URL:
>          >
>         https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>          >       3.
>          >          Request Method:
>          >          OPTIONS
>          >       4.
>          >          Status Code:
>          >          200 OK
>          >   1. Response Headersview source
>          >       1.
>          >          Access-Control-Allow-Headers:
>          >          Accept, Authorization, Head
>          >       2.
>          >          Access-Control-Allow-Methods:
>          >          OPTIONS, GET, POST, DELETE, PUT
>          >       3.
>          >          Access-Control-Allow-Origin:
>          > http://localhost:8383
>          >       4.
>          >          Access-Control-Max-Age:
>          >          0
>          >       5.
>          >          Connection:
>          >          keep-alive
>          >       6.
>          >          Date:
>          >          Thu, 27 Aug 2015 18:44:39 GMT
>          >       7.
>          >          Server:
>          >          WildFly/8
>          >       8.
>          >          Transfer-Encoding:
>          >          chunked
>          >       9.
>          >          X-Powered-By:
>          >          Undertow/1
>          >   2. Request Headersview source
>          >       1.
>          >          Accept:
>          >          */*
>          >       2.
>          >          Accept-Encoding:
>          >          gzip, deflate, sdch
>          >       3.
>          >          Accept-Language:
>          >          en-US,en;q=0.8,ar;q=0.6
>          >       4.
>          >          Access-Control-Request-Headers:
>          >          accept, authorization
>          >       5.
>          >          Access-Control-Request-Method:
>          >          POST
>          >       6.
>          >          Cache-Control:
>          >          no-cache
>          >       7.
>          >          Connection:
>          >          keep-alive
>          >       8.
>          >          Host:
>          >          dev-internal-api.expdev.local
>          >       9.
>          >          Origin:
>          > http://localhost:8383
>          >      10.
>          >          Pragma:
>          >          no-cache
>          >      11.
>          >          Referer:
>          >
>         http://localhost:8383/keycloak-oauth/index.html?code=1SnLPvM2b4cuXeMp3w8s-3ETKBuI7hyPFy6mRs3hMy4.677e4cee-3dd7-4d19-9268-5045d171327
>          >
>          >
>          >
>          >
>          > POST HEADER
>          >
>          >           1.
>          >              Remote Address:
>          > 172.26.209.66:443 <http://172.26.209.66:443>
>         <http://172.26.209.66:443>
>          >           2.
>          >              Request URL:
>          >
>         https://dev-internal-api.expdev.local/apiman-gateway/express/integration/1.0/test/methods/post
>          >           3.
>          >              Request Method:
>          >              POST
>          >           4.
>          >              Status Code:
>          >              403 Forbidden
>          >       1. Response Headersview source
>          >           1.
>          >              Access-Control-Allow-Origin:
>          > http://localhost:8383
>          >           2.
>          >              Connection:
>          >              keep-alive
>          >           3.
>          >              Content-Length:
>          >              195
>          >           4.
>          >              Content-Type:
>          >              application/json
>          >           5.
>          >              Date:
>          >              Thu, 27 Aug 2015 18:44:39 GMT
>          >           6.
>          >              Server:
>          >              WildFly/8
>          >           7.
>          >              X-Policy-Failure-Code:
>          >              400
>          >           8.
>          >              X-Policy-Failure-Message:
>          >              CORS: Invalid preflight request; must use
>         OPTIONS verb.
>          >           9.
>          >              X-Policy-Failure-Type:
>          >              Authorization
>          >          10.
>          >              X-Powered-By:
>          >              Undertow/1
>          >       2. Request Headersview source
>          >           1.
>          >              Accept:
>          >              application/json, text/plain, */*
>          >           2.
>          >              Accept-Encoding:
>          >              gzip, deflate
>          >           3.
>          >              Accept-Language:
>          >              en-US,en;q=0.8,ar;q=0.6
>          >           4.
>          >              Authorization:
>          >              Bearer
>          >
>         eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJkYTI.................................qoQRgKQ
>          >           5.
>          >              Cache-Control:
>          >              no-cache
>          >           6.
>          >              Connection:
>          >              keep-alive
>          >           7.
>          >              Content-Length:
>          >              0
>          >           8.
>          >              Host:
>          >              dev-internal-api.expdev.local
>          >           9.
>          >              Origin:
>          > http://localhost:8383
>          >          10.
>          >              Pragma:
>          >              no-cache
>          >          11.
>          >
>          > 12.
>          >
>          >
>          >
>          >
>          > _______________________________________________
>          > Apiman-user mailing list
>          > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>          > https://lists.jboss.org/mailman/listinfo/apiman-user
>          >
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>


From cmoulliard at redhat.com  Mon Aug 31 13:38:34 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 31 Aug 2015 19:38:34 +0200
Subject: [Apiman-user] Apiman & Keycloak
Message-ID: <55E4911A.8050904@redhat.com>

Hi,

I have already asked this question but I need some help to figure out 
what are the steps required to setup Oauth 2 with Keycloak as I'm 
preparing a demo (https://github.com/FuseByExample/rest-dsl-in-action) 
covering the point about how to secure & govern Camel REST DSL endpoints 
on JBoss Fuse using Apiman & Keycloak ?

I just need the list of the steps to perform from the Web Site. Base on 
the input, I will take some screenshots and include the instructions 
within the demo content. Such input could be reused to write a blog 
article too ;-)

Regards,

Charles

From rafaelcba at gmail.com  Mon Aug 31 17:48:58 2015
From: rafaelcba at gmail.com (Rafael Soares)
Date: Mon, 31 Aug 2015 18:48:58 -0300
Subject: [Apiman-user] Apiman & Keycloak
In-Reply-To: <55E4911A.8050904@redhat.com>
References: <55E4911A.8050904@redhat.com>
Message-ID: <CAE2FsvUx-n6-=sayMeWxdDi-jugOXrnQgeUd4a3-xd2o62uWrw@mail.gmail.com>

Charles,

 Recently I followed the "*Keycloak and dagger: Securing your services with
OAuth2*" tutorial [1] and it worked fine! This howto is great!

You don't need to do anything on the Fuse/Camel side. All setup is done in
the ApiMan side. ApiMan comes with a KeyCloak service embedded and all you
need to do is install the Apiman oauth2 keycloak plugin and configure your
service policy to use it. The tutorial [1] describes each step in detail.

[1]
http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html



________________________
Rafael Torres Coelho Soares

On Mon, Aug 31, 2015 at 2:38 PM, Charles Moulliard <cmoulliard at redhat.com>
wrote:

> Hi,
>
> I have already asked this question but I need some help to figure out
> what are the steps required to setup Oauth 2 with Keycloak as I'm
> preparing a demo (https://github.com/FuseByExample/rest-dsl-in-action)
> covering the point about how to secure & govern Camel REST DSL endpoints
> on JBoss Fuse using Apiman & Keycloak ?
>
> I just need the list of the steps to perform from the Web Site. Base on
> the input, I will take some screenshots and include the instructions
> within the demo content. Such input could be reused to write a blog
> article too ;-)
>
> Regards,
>
> Charles
> _______________________________________________
> 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/20150831/72ecb282/attachment.html 

From eric.wittmann at redhat.com  Mon Aug 31 20:19:45 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 31 Aug 2015 20:19:45 -0400
Subject: [Apiman-user] Apiman & Keycloak
In-Reply-To: <CAE2FsvUx-n6-=sayMeWxdDi-jugOXrnQgeUd4a3-xd2o62uWrw@mail.gmail.com>
References: <55E4911A.8050904@redhat.com>
	<CAE2FsvUx-n6-=sayMeWxdDi-jugOXrnQgeUd4a3-xd2o62uWrw@mail.gmail.com>
Message-ID: <55E4EF21.4040402@redhat.com>

+1

Thanks for responding, Rafael. I had intended to link this very same 
tutorial but then it slipped my mind. :)

On 8/31/2015 5:48 PM, Rafael Soares wrote:
> Charles,
>
>   Recently I followed the "/Keycloak and dagger: Securing your services
> with OAuth2/" tutorial [1] and it worked fine! This howto is great!
>
> You don't need to do anything on the Fuse/Camel side. All setup is done
> in the ApiMan side. ApiMan comes with a KeyCloak service embedded and
> all you need to do is install the Apiman oauth2 keycloak plugin and
> configure your service policy to use it. The tutorial [1] describes each
> step in detail.
>
> [1]
> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html
>
>
>
> ________________________
> Rafael Torres Coelho Soares
>
> On Mon, Aug 31, 2015 at 2:38 PM, Charles Moulliard
> <cmoulliard at redhat.com <mailto:cmoulliard at redhat.com>> wrote:
>
>     Hi,
>
>     I have already asked this question but I need some help to figure out
>     what are the steps required to setup Oauth 2 with Keycloak as I'm
>     preparing a demo (https://github.com/FuseByExample/rest-dsl-in-action)
>     covering the point about how to secure & govern Camel REST DSL endpoints
>     on JBoss Fuse using Apiman & Keycloak ?
>
>     I just need the list of the steps to perform from the Web Site. Base on
>     the input, I will take some screenshots and include the instructions
>     within the demo content. Such input could be reused to write a blog
>     article too ;-)
>
>     Regards,
>
>     Charles
>     _______________________________________________
>     Apiman-user mailing list
>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>