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@redhat.com<mailto:eric.wittmann@redhat.com<mailto:marc.savy@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@redhat.com <mailto:eric.wittmann@redhat.com><mailto:Apiman-user@lists.jboss.org>>>
<mailto:eric.wittmann@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@redhat.com <mailto:marc.savy@redhat.com>
<mailto:marc.savy@redhat.com <mailto:marc.savy@redhat.com>>
<mailto:marc.savy@redhat.com
<mailto:marc.savy@redhat.com> <mailto:marc.savy@redhat.com
<mailto:marc.savy@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@lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
_______________________________________________
Apiman-user mailing list
Apiman-user@lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user