[wildfly-dev] Push for CORS in WildFly 8

[ssilvert at redhat.com]

On 12/10/2013 12:33 PM, Darran Lofthouse wrote:
> If we are going to support cross origin requests we need to do it
> properly, the current behaviour is there to solve a specific problem
> of the server being vulnerable to cross site scripting attacks -
> relaxing it without a complete solution is just going to re-introduce
> that vulnerability.
>
> Based on the current commit there are two things we would really need
> to do: -
>  1 - Instead of faking authentication move Options handling to it's
> own handler before authentication.
>  2 - Proper support for configured alternative origins.
>
> Maybe we can just get away with a configured list of alternative
> origins to allow through but without exploring the origins for the
> alternative distribution approaches we can not be sure that would not
> leave an alternative option for malicious calls.
>
> At the moment I have not seen anything to suggest we need anything
> more dynamic but at this point I don't know if we have all the
> distribution approaches defined.
>
> I will have a look at what we can do for the static config approach.
+1 Static config would be great for now.
>
> Regards,
> Darran Lofthouse.
>
> On 10/12/13 16:53, ssilvert at redhat.com wrote:
>> 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
>>>>>>
>>>>
>>