Reply
New Contributor
Posts: 2
Registered: ‎02-05-2017

Re: New Cloudera installation: Hue - Bad Request (400)

Just to confirm:

 

Adding:

 

[desktop]

allowed_hosts=*

 

as indicated in this post solved my bad request problem.

 

Thank you for the solution.

Explorer
Posts: 11
Registered: ‎02-15-2017

Re: New Cloudera installation: Hue - Bad Request (400)

[ Edited ]

Hey Ben, 

 

Many many thanks!! We had the same error [400] with CM 5.9 with embedded PostGRESql db

I confirm that this has resolved our issue. 

 

A gist of out setup: 

Platform: AWS, 4 x t2.medium, 50GiB EBS

OS: CentOS 6 with updates HVM

 

Thanks again!!

Explorer
Posts: 21
Registered: ‎10-27-2015

Re: New Cloudera installation: Hue - Bad Request (400)

I would like to understand what security risk this change addresses.  From what I can tell, this will adversly impact any cloud deployment that is using default cloud-provided domain names (ie AWS with default VPC configuration) and it will not affect any environment (ie on-premesis) where the clients are in the same domain as Hue.  The only situation that I have been able to imagine is one where Hue is sitting on the public Internet at hue.domain with a very loose firewall (if any) but we want only clients (laptop.domain) to be served.

 

Can the Hue Team elaborate on how allowed_hosts=".domain" can possibly help my customers and why every AWS install I do with 5.10 will require me to revert to allowed_hosts="*"?

Posts: 434
Topics: 1
Kudos: 102
Solutions: 54
Registered: ‎04-22-2014

Re: New Cloudera installation: Hue - Bad Request (400)

@mjarnold,

 

I posted this somewhere else earlier and I think it will help answer your question:

 

Workaround to revert to pre-CDH 5.10 behavior:

  • Edit Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini
  • add allowed_hosts in the [desktop] section like so:
[desktop]
allowed_hosts=*
  • Restart Hue

NOTE: The goal in changing the default to something more restrictive was to improve security. Now that we are aware of the security measure, if desired, restriction can be added via a comma-separated list of hosts and IPs like this:

[desktop]
allowed_hosts=.cloudera.com,0.0.0.0,172.31.114.79

See the following on how to configure if you choose that route:

https://docs.djangoproject.com/en/1.10/ref/settings/#allowed-hosts

 

To round out the above explanation, before CDH 5.10, "allowed_hosts=*" was the default.  We tried changing the default to help promote security as outlined in the above Django page.

 

Since our change to allowed_hosts to help enhance security had unanticipated negative experiences for existing users, we are reverting the CDH default to "allowed_hosts=*".  We'll opt to document it better and also build in validation warnings in Cloudera Manager to strongly recommend not leaving "allowed_hosts=*" unless that is the desired configuration.

 

The security risk is described in the django documentation (see the link above).

 

Ben

New Contributor
Posts: 1
Registered: ‎03-10-2017

Re: New Cloudera installation: Hue - Bad Request (400)

same problem here

i am getting " server not found " when i open hue web UI, and i tried to access with the external ip address:8888, i am getting "Bad Request(400) ".

 

i have been trying to debug the error but no use

have you solved your error ? if yes can you share the solution that helps alot

Thank you

Cloudera Employee
Posts: 16
Registered: ‎08-16-2016

Re: New Cloudera installation: Hue - Bad Request (400)

The answer is one post above....

Highlighted
Explorer
Posts: 21
Registered: ‎10-27-2015

Re: New Cloudera installation: Hue - Bad Request (400)

@bgooley,

 

So to clarify my assumptions and (mis)understandings:

 

The allowed_hosts setting is not checking the HTTP client's DNS domain.  It is the Hue webserver framework (ie Django) checking the HTTP Host: header that the client sends.

 

In my case of AWS VPC with default public subnet configuration, my web browser thinks I am talking to ec2-54-50-32-4.compute-1.amazonaws.com and sends that as the Host: header.  The Hue server sees that, expecting something more like ip-10-1-2-3.ec2.internal, and replies with the "Bad Request (400)" to the client.

 

Announcements