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.
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