[Apiman-user] Hawtio Based API Manager UI Developer Setup Issues
Eric Wittmann
eric.wittmann at redhat.com
Mon Jun 15 09:28:05 EDT 2015
I just tested this and was (sadly) able to reproduce the problem. The
reason I didn't hit this before was that I use the development server
instead of using the full WF8 instance.
For reference, the development server is described here:
http://www.apiman.io/blog/eclipse/development/maven/2015/06/04/dev-environment.html
In any case, what seems to be happening is that a CORS preflight OPTIONS
request does not contain the Authorization info. Keycloak is
redirecting the OPTIONS request to the login page. :(
So we need to figure out how to get keycloak to do the right thing for a
preflight request. It might be a bug in KC or just a configuration
issue on our side. We'll look into this asap. But until then, your
workaround is fine - or else follow the blog post above for how to set
up a more nimble dev environment.
-Eric
JIRA Issue for reference: https://issues.jboss.org/browse/APIMAN-476
On 6/15/2015 8:27 AM, Eric Wittmann wrote:
> This is a fine workaround for development, but I'm surprised you ran
> into a CORS problem. There should be a CORS filter enabled for /apiman
> allowing the UI to work across origins. I do this all the time when
> using gulp to develop the UI.
>
> What is your server setup? Are you using the standard WF8 distribution?
>
> If CORS is broken on the server we need to know. I'll go test it right
> now! :)
>
> -Eric
>
> On 6/15/2015 12:24 AM, Brandon Gaisford wrote:
>>
>> Hey All,
>>
>> After googling around a bit and some trial and error, I was able to find
>> a work around for the CORS issue. One can start up chrome using a
>> disable web security flag[1]. As per the link,
>>
>> On OS X:
>>
>> /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome
>> —disable-web-security
>>
>> On Windows:
>>
>> Chrome.exe —disable-web-security
>>
>> The link also outlines steps for Firefox, but I haven’t tried it.
>>
>> Brandon
>>
>> [1] https://blog.nraboy.com/2014/08/bypass-cors-errors-testing-apis-locally/
>>
>>
>> On Jun 14, 2015, at 11:39 AM, Brandon Gaisford <bgaisford at punagroup.com
>> <mailto:bgaisford at punagroup.com>> wrote:
>>
>>>
>>> I’m following the Hawtio README, the setup seems fine and all is running.
>>>
>>> Node starts:
>>>
>>> $ gulp
>>> [11:31:55] Server started http://localhost:2772
>>> [11:31:55] LiveReload started on port 35729
>>>
>>> When I make updates in the Hawtio src tree, the server reloads, all
>>> looks good.
>>>
>>> The gateway and apiman services are running:
>>>
>>> GET: http://localhost:8080/apiman/system/status (had to login)
>>>
>>> {"up":true,"version":"1.1.4-SNAPSHOT"}
>>>
>>> Decided to start up firebug in Firefox and see if I could seed
>>> anything. Looks like an error early in UI startup:
>>>
>>> Cross-Origin Request Blocked: The Same Origin Policy disallows reading
>>> the remote resource at http://localhost:8080/apiman/system/status.
>>> (Reason: CORS header ‘Access-Control-Allow-Origin' missing).
>>>
>>> What is the correct way to get around this CORS stuff during
>>> Node/Hawtio development?
>>>
>>> Thanks,
>>>
>>> Brandon
>>> _______________________________________________
>>> 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
>
More information about the Apiman-user
mailing list