[wildfly-dev] Push for CORS in WildFly 8
ssilvert at redhat.com
ssilvert at redhat.com
Tue Dec 10 11:53:55 EST 2013
On 12/10/2013 11:26 AM, Darran Lofthouse wrote:
> I am not sure if I am missing something, are you proposing that we
> stop the rejection of requests that have a different origin?
Not by default. Just as an option so that we can start working with
CORS on the front end.
>
> On 10/12/13 15:58, ssilvert at redhat.com wrote:
>> On 12/10/2013 9:35 AM, Darran Lofthouse wrote:
>>> To get this implemented the first thing we need is some detailed
>>> analysis of how the Host and Origin headers will be used by different
>>> browsers for the different distribution approaches we will take for
>>> the different consoles.
>>>
>>> We will need to take into account how this could be affected by
>>> proxies / firewalls etc...
>>>
>>> Considering the different distribution approaches we will need to
>>> consider implications for malicious consoles / web pages etc possibly
>>> from the same source and any options to mitigate this.
>>>
>>> But then overall it should be a case of configuration to allow a
>>> relaxation of the Host / Origin match with acceptable values.
>> Let's do this last part first. It's not much effort to enable CORS.
>> Here is Herald's commit:
>> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69e36269b
>>
>>
>> If we put this into WildFly 8 (disabled by default), it would allow us
>> to start working with it and better perform the analysis suggested by
>> Darran.
>>
>> I propose that Herald update his commit to work with the latest code and
>> we go ahead and get that in. Any objections?
>>
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 10/12/13 13:17, ssilvert at redhat.com wrote:
>>>> Re: https://issues.jboss.org/browse/WFLY-1014
>>>>
>>>> I'd like to request that we take a harder look at getting WFLY-1014
>>>> done. This feature allows CORS requests into the HTTP management
>>>> endpoint.
>>>>
>>>> This would solve two problems:
>>>> 1) The web console must ship with WildFly and must be downloaded from
>>>> the WildFly instance it is talking to.
>>>> 2) No other console is allowed to use the HTTP management
>>>> endpoint. So,
>>>> a layered product's console can not control its own subsystem.
>>>>
>>>> Herald gives a nice overview of what this would mean for the Web
>>>> Console:
>>>> http://hpehl.info/independent-jboss-admin-console.html
>>>>
>>>> It would be very beneficial for other products as well. Can we get
>>>> this
>>>> done?
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
More information about the wildfly-dev
mailing list