Support Questions
Find answers, ask questions, and share your expertise
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

New Cloudera installation: Hue - Bad Request (400)

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


I believe this Hue code change was made for security reasons. The new default is that only hosts on the same domain as the Hue server are allowed to connect. 


As noted in the ini file comments, instead of allowing all domains to connect, one could also list out each allowed domain in a comma separated list:





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


@kfc @Burkhard @CloudOpsProd


Can you all post the stdout of Hue so we can confirm that it is the same issue and not just the same error?


Can you also detail how you installed CDH and specifically Hue?  Did you use parcels or packages?  Did you add it during the Cluster Install Wizard or using the Add Service Wizard?  Did you install it by hand?


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


seems that nobody is reading the full topic so ill trie to summarize a bit.

tested System:  Ubuntu 14 /Debian 8 /CentOS7
Cloud env: aws ec2 and gcloud comuting (! i think here is the problem CLOUD)

Installing like install path A(POC) with clouderamanager.bin or installpath B with embedded database.

Cloudera Manager and other apps are running well and are useable!
Only the hue app is not accessable from another host. 
When i curl/wget the hue URL from the shell of the ec2 machine it is working but via clientbrowser from my notebook it didnt.


Via ClouderaManager open the Hue Config -> advanced and search the property with "hue_safety_valve.ini" in the description text and add following lines:



save-> restart hue service -> happy hueing!


@romanir there was a typo in your solution thats why it didnt work!
@Allbeware there a two "security config parts" use the one with "hue_safety_valve.ini" in the description!

thanks for your help @ all


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


I asked my questions to clarify who was having the issue that the OP had.

After installing using the embedded DB it didn't properly run the sycndb command. The OP had the correct syntax and right location. He was not able to sync the db or access Hue. His fix was to set up a MySQL instance and use that.

It is still possible related but his issue seemed to indicate that something went wrong with the install using the embedded DB.

I am glad that you got your issue resolved.

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

Super Guru


....removed content since it was posted prematurely.  Full post follows...


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

Super Guru



There are two issues here:




This is seen in the error log of Hue:


ProgrammingError: column beeswax_savedquery.is_redacted does not exist
LINE 1: ...ry"."is_auto", "beeswax_savedquery"."is_trashed", "beeswax_s...




When trying to access the Hue UI, the browser sees the following error:


Bad Request (400)


The first issue cannot be the direct cause of the second.  Bad Request (400) is returned by django and django does not look at beeswax tables.  In my tests, I also saw the "column beeswax_savedquery.is_redacted does not exist" but saw no problems and noted that the "migrate" scripts worked fine.


Evidence can be observed with the following steps for a Cloudera Manager managed CDH:


# export HUE_CONF_DIR=/var/run/cloudera-scm-agent/process/`ls -lrt /var/run/cloudera-scm-agent/process/ |awk '{print $9}' |grep HUE_SERVER| tail -1`


# HUE_IGNORE_PASSWORD_SCRIPT_ERRORS=1 HUE_DATABASE_PASSWORD=<password> /opt/cloudera/parcels/CDH/lib/hue/build/env/bin/hue migrate --list


The output shows (via the stars) what migration scripts have been run successfully.  Even though I got the "column does not exist" error, my embedded Hue db shows success:


(*) 0001_initial
(*) 0002_auto__add_field_queryhistory_notify
(*) 0003_auto__add_field_queryhistory_server_name__add_field_queryhistory_serve
(*) 0004_auto__add_session__add_field_queryhistory_server_type__add_field_query
(*) 0005_auto__add_field_queryhistory_statement_number
(*) 0006_auto__add_field_session_application
(*) 0007_auto__add_field_savedquery_is_trashed
(*) 0008_auto__add_field_queryhistory_query_type
(*) 0009_auto__add_field_savedquery_is_redacted__add_field_queryhistory_is_reda
(*) 0009_auto__chg_field_queryhistory_server_port
(*) 0010_merge_database_state
(*) 0011_auto__chg_field_savedquery_name
(*) 0012_auto__add_field_queryhistory_extra
(*) 0013_auto__add_field_session_properties
(*) 0014_auto__add_field_queryhistory_is_cleared




Unless we find evidence to the contrary, what I see is this:




Bad Request (400) is likely resolved by configuring "allowed_hosts" to allow access from the domain the browser is reporting.




The "column beeswax_savedquery.is_redacted does not exist" error is likely due to a minor coding issue that we can work to resolve.  It appears that the "sync" operation looks for the "is_redacted" column on first run before the "migrate" scripts are run to add it.  See in the following file:




def forwards(self, orm):
    # Adding field 'SavedQuery.is_redacted'
    db.add_column('beeswax_savedquery', 'is_redacted',


I know that was a lot of information, but I wanted to make sure that we treated the column issue and the Bad Request issue separately. 





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


I concur and excellent write up.

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

Super Guru

As a quick follow-up, I opened an internal Cloudera Jira so we can review how to address that 'sync' exception.  Hue dev team will have a look.  It appears innocuous, but we'll make sure.

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

New Contributor

Just to confirm:







as indicated in this post solved my bad request problem.


Thank you for the solution.

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="*"?

Don't have an account?
Coming from Hortonworks? Activate your account here