CORS preflight OPTIONS request requires Authorization header
by Melih Ozdemirkan
I have an API provisioned on APIMAN with Keycloak OAuth Policy and CORS Policy (using APIMAN Plugins) . Onclient side, I get the JWT token from Keycloak and add authorization header to get request sent to APIMAN for my own API. Problem is that APIMAN rejects OPTIONS preflight with 401 Unauthorized with message "OAuth2 'Authorization' header or 'access_token' query parameter must be provided."
I am using APIMAN 1.2.7_final . I applied workaround in the JIRA issue given below but it didn't work for me. Does it work for both APIMAN's own rest endpoints and my own API's. I suppose it is not valid for the later one.
http://lists.jboss.org/pipermail/apiman-user/2016-July/000727.html
https://issues.jboss.org/browse/APIMAN-1209
TOKEN REQUEST TO KEYCLOAK
General
Request URL:http://localhost:8280/auth/realms/company/protocol/openid-connect/token
Request Method:POST
Status Code:200 OK
Remote Address:127.0.0.1:8280
Response Headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:8080
Access-Control-Expose-Headers:Access-Control-Allow-Methods
Connection:keep-alive
Content-Length:3175
Content-Type:application/json
Date:Thu, 25 Aug 2016 07:22:59 GMT
Server:WildFly/10
X-Powered-By:Undertow/1
Request Headers
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Content-Length:78
Content-Type:application/x-www-form-urlencoded
Host:localhost:8280
Origin:http://localhost:8080
Referer:http://localhost:8080/login-services/login.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Form Data
view source
view URL encoded
username:username
password:pasword
grant_type:password
client_id:company
GET REQUEST TO API on APIMAN
General
Request URL:http://localhost:8280/apiman-gateway/client/test-services-ws/1.0/getuser/
Request Method:OPTIONS
Status Code:401 Unauthorized
Remote Address:127.0.0.1:8280
Response Headers
Connection:keep-alive
Content-Type:application/json
Date:Thu, 25 Aug 2016 07:22:59 GMT
Server:WildFly/10
Transfer-Encoding:chunked
X-Policy-Failure-Code:11005
X-Policy-Failure-Message:OAuth2 'Authorization' header or 'access_token' query parameter must be provided.
X-Policy-Failure-Type:Authentication
X-Powered-By:Undertow/1
Request Headers
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:GET
Connection:keep-alive
Host:localhost:8280
Origin:http://localhost:8080
Referer:http://localhost:8080/login-services/login.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
İyi Çalışmalar,
Melih Özdemirkan
AvivaSA Emeklilik ve Hayat A.Ş.
Kanal ve Entegrasyon Uygulamaları
Danışman
www.avivasa.com.tr<http://www.avivasa.com.tr/>
Saray Mah. Dr. Adnan Büyükdeniz Cad. No:12 34768
Ümraniye - İstanbul
[http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_01.png]<https://www.avivasa.com.tr/gelecegini-biriktirenler-kulubu-nedir> [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_02.png] <https://www.avivasa.com.tr/gelecegini-biriktirenler-kulubu-nedir> [http://www.avivasa.com.tr/i/Assets/AvivaSA_Imza/images//gelecegini_03.png] <https://www.avivasa.com.tr/gelecegini-biriktirenler-kulubu-nedir>
Bu e-postanin içerdigi bilgiler (ekleri dahil olmak üzere) gizlidir. Onayimiz olmaksizin üçüncü kisilere açiklanamaz. Bu mesajin gönderilmek istendigi kisi degilseniz, lütfen mesaji sisteminizden derhal siliniz. AvivaSA Emeklilik ve Hayat A.S. bu mesajin içerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda bir garanti vermemektedir. Bu nedenle bilgilerin ne sekilde olursa olsun içeriginden, iletilmesinden, alinmasindan, saklanmasindan sorumlu degildir. Bu mesajin bilinen virüslere karsi kontrolleri AvivaSA Emeklilik ve Hayat A.S. tarafindan yapilmistir. Ancak internet iletisiminde güvenlik ve hatasiz gönderim garanti edilemeyeceginden, mesajin yerine ulasmamasi, geç ulasmasi, içeriginin bozulmasi ya da mesajin virüs tasimasi gibi problemler olusabilir. AvivaSA Emeklilik ve Hayat A.S. bu tip sorunlardan sorumlu tutulmaz. Bu mesajin içerigi yazarina ait olup AvivaSA Emeklilik ve Hayat A.S.'nin görüslerini içermeyebilir.
The information contained in this e-mail (including any attachments) is confidential. It must not be disclosed to any person without our authority. If you are not the intended recipient, please delete it from your system immediately. AvivaSA Emeklilik ve Hayat A.S. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. This message is scanned for known viruses by AvivaSA Emeklilik ve Hayat A.S. But Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The AvivaSA Emeklilik ve Hayat A.S. therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of AvivaSA Emeklilik ve Hayat A.S.
7 years, 7 months
Update: apiman and 3scale
by Eric Wittmann
Hey everyone. We mentioned it a couple of months ago when the news was
fresh, but just as a reminder, Red Hat has acquired 3scale technologies.
This has resulted in a change in priority with respect to API
Management work within the company. As you can imagine, the apiman team
in particular has been impacted.
To help everyone understand the future of apiman, we've put together a
blog post to answer some common questions. You can find it here:
http://www.apiman.io/blog/apiman/3scale/2016/08/19/3scale-apiman-part2.html
Anyone with additional questions or comments, please feel free to do so
here, or in any of the other various places we try to communicate
(comments on the blog post, IRC, twitter, etc). Always happy to have
conversations with our fantastic community! :)
-Eric
7 years, 8 months
Client App and CORS
by Harry Trinta
Dears,
I've created a "client app" that has a lot of contracts with a lot of APIs.
I'm having the following problem:
In Cross-origen, when the browser send a OPTIONS request, it does not send
the parameter X-API-Key. Then, the apiman returns a error: "API not public".
Is possible to disable the X-API-Key validation of a "client app" when the
request is OPTIONS type?
Thanks,
Harry
7 years, 8 months
