[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