Re: [wildfly-dev] Push for CORS in WildFly 8

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.

Regards, Darran Lofthouse. On 10/12/13 16:53, ssilvert(a)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(a)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/89af5ba711502005275411820b8198f69... >>> >>> >>> >>> 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(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> >