Project

General

Profile

Bug #7049

9.3 BETA + 9.1.1 config => WebGUI authentication failure

Added by Scott Bolte almost 6 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Suraj Ravichandran
Category:
Middleware
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

When I load a 9.1.1 configuration file into a brand new install of 9.3 BETA (2014-12-08 build) I get "_CSRF verification failed. Request aborted_" when I tried to log in via Web GUI. Interestingly, this is different behavior than when I loaded the same 9.1.1 configuration into the November 7th 9.3 BETA build.

Now here is what I did:

  1. Two days ago I unwittingly installed an outdated November 7th build of 9.3 BETA. It was a clean install from ISO on hardware that's been running FreeNAS for year. It worked with factory default settings.
  2. I uploaded my 9.1.1 configuration, rebooted, and it worked with those settings as well. However, that build included a bug that prevented software updates so I needed to try again. (See https://bugs.freenas.org/issues/7004 for details)
  3. Yesterday I did another ISO install -- a Fresh Install not an upgrade -- using the December 8th nightly build. As with the day before, the WebGUI worked fine with the factory defaults.
  4. Once again, I uploaded my 9.1.1 configuration. However, this time, after it rebooted itself, and asked for the root password, I got the following error:
Forbidden (403)
CSRF verification failed. Request aborted.

More information is available with DEBUG=True.

Here are some additional details:

  • I am able to reset the password from the console.
  • I am able to log in with the root password using SSH.
  • I've tried with both Safari and Firefox.
  • I've tried with both browsers after deleting the cookies; cookies that include csrftoken by the way.
  • I've searched through the bug backlog and, aside from https://bugs.freenas.org/issues/5595, did not find a similar problem. That unresolved report feels like a different root cause in any case.
  • I repeated the fresh install from ISO and reproduced the problem.
  • I've edited /usr/local/www/freenasUI/settings.py to set DEBUG to True. See below for the longer, but no more informative error message.
Forbidden (403)
CSRF verification failed. Request aborted.
Help
Reason given for failure:
    CSRF cookie not set.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:
* Your browser is accepting cookies.
* The view function uses RequestContext for the template, instead of Context.
* In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
* If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.
You can customize this page using the CSRF_FAILURE_VIEW setting.

What should I do to diagnose the problem that was introduced between November 7th and December 8th?

FYI, I can easily edit my 9.1.1 SQLite configuration to help figure this one out, but I need to know what to change. I also have ssh/console access so I can poke around on the NAS as well.

django.patch (659 Bytes) django.patch Suraj Ravichandran, 12/09/2014 05:09 PM

Associated revisions

Revision 4905b52c (diff)
Added by Suraj Ravichandran almost 6 years ago

Fix: 9.3 BETA + 9.1.1 config => WebGUI authentication failure Make Django rc.d script aware of an invalid or missing certificate, even when https gui protocol is set. Ticket: #7049

Revision d6ce4149 (diff)
Added by Suraj Ravichandran almost 6 years ago

Fix: 9.3 BETA + 9.1.1 config => WebGUI authentication failure Make Django rc.d script aware of an invalid or missing certificate, even when https gui protocol is set. Ticket: #7049

Revision 93fb4a1c (diff)
Added by Suraj Ravichandran over 5 years ago

Run the django (rc.d script) after ix-nginx as the new django secure cookies rely on ix-nginx validating the certificate and deciding if its valid or not and in the case it is not then it also notifies django to turn off secure cookies as 'http' fallback is going on. Also run the cert migration code in ix-update after uploaded.db is renamed and copied over as freenas-v1.db, not doing this resulted in your previous certificate getting lost when you did a fresh 9.3 install and uploaded a 9.2.x config file containing a certificate. This should (hopefully!) fix the folowing bugs: Ticket: #7049 (9.3 BETA + 9.1.1 config => WebGUI authentication failure) Ticket: #7196 (Restoring config (9.2.1.9) locks you out of web interface)

Revision 63ab45e6 (diff)
Added by Suraj Ravichandran over 5 years ago

Run the django (rc.d script) after ix-nginx as the new django secure cookies rely on ix-nginx validating the certificate and deciding if its valid or not and in the case it is not then it also notifies django to turn off secure cookies as 'http' fallback is going on. Also run the cert migration code in ix-update after uploaded.db is renamed and copied over as freenas-v1.db, not doing this resulted in your previous certificate getting lost when you did a fresh 9.3 install and uploaded a 9.2.x config file containing a certificate. This should (hopefully!) fix the folowing bugs: Ticket: #7049 (9.3 BETA + 9.1.1 config => WebGUI authentication failure) Ticket: #7196 (Restoring config (9.2.1.9) locks you out of web interface)

History

#1 Updated by Suraj Ravichandran almost 6 years ago

  • Status changed from Unscreened to 15
  • Assignee set to Suraj Ravichandran

Could paste your django settings file.

It is located at /usr/local/www/freenasUI/settings.py.

#2 Updated by Scott Bolte almost 6 years ago

I just did a fresh install of 9.3-RELEASE -- same problem as with 9.3-BETA.

Here is the settings.py file from that 9.3-RELEASE install after applying the 9.1.1 config:

#+
# Copyright 2010-2012 iXsystems, Inc.
# All rights reserved
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted providing that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
# IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
#####################################################################

# Django settings for FreeNAS project.

import os
import sys

sys.path.append('/usr/local/lib')

HERE = os.path.abspath(os.path.dirname(__file__))

DEBUG = False
#DEBUG = True
#TASTYPIE_FULL_DEBUG = True
TEMPLATE_DEBUG = DEBUG
LOGIN_REDIRECT_URL = '/'
LOGIN_URL = '/account/login/'
LOGOUT_URL = '/account/logout/'

ADMINS = (
     ('iXsystems, Inc.', 'freenas@ixsystems.com'),
)

MANAGERS = ADMINS

DATABASE_PATH = '/data/freenas-v1.db'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': DATABASE_PATH,
        'TEST_NAME': ':memory:',
    }
}

""" 
Make sure the database is never world readable
""" 
if os.path.exists(DATABASE_PATH):
    stat = os.stat(DATABASE_PATH)
    #TODO use pwd.getpwnam/grp.getgrnam?
    #0 - root
    #5 - operator
    if stat.st_uid != 0 or stat.st_gid != 5:
        os.chown(DATABASE_PATH, 0, 5)
    mode = stat.st_mode & 0xfff
    if mode != 0o640:
        os.chmod(DATABASE_PATH, 0o640)

# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# If running in a Windows environment this must be set to the same as your
# system time zone.
TIME_ZONE = None

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'

SITE_ID = 1

# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale
USE_L10N = True

# Absolute path to the directory that holds media.
# Example: "/home/media/media.lawrence.com/" 
MEDIA_ROOT = os.path.join(HERE, 'media')
MEDIA_URL = '/media/'

# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/" 
STATIC_ROOT = os.path.join(HERE, "static")

# URL prefix for static files.
# Example: "http://media.lawrence.com/static/" 
STATIC_URL = '/static/'

STATICFILES_DIRS = (
    os.path.join(HERE, "fnstatic"),
)

# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
#    'django.contrib.staticfiles.finders.DefaultStorageFinder',
)

# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.Loader',
    'django.template.loaders.app_directories.Loader',
)

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    #'freenasUI.freeadmin.middleware.ProfileMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'freenasUI.freeadmin.middleware.LocaleMiddleware',
    'freenasUI.freeadmin.middleware.CatchError',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'freenasUI.freeadmin.middleware.RequireLoginMiddleware',
)

DOJANGO_DOJO_PROFILE = 'local_release'
DOJANGO_DOJO_VERSION = '1.10.1'
#DOJANGO_DOJO_BUILD_VERSION = '1.6.0b1'
DOJANGO_DOJO_DEBUG = True

ROOT_URLCONF = 'freenasUI.urls'

TEMPLATE_DIRS = (
    os.path.join(HERE, 'templates'),
)

TEMPLATE_CONTEXT_PROCESSORS = (
        'django.core.context_processors.request',
        'django.contrib.auth.context_processors.auth',
        "django.core.context_processors.i18n",
        "django.core.context_processors.media",
        "django.core.context_processors.static",
        'dojango.context_processors.config',
        )

LOCALE_PATHS = (
    os.path.join(HERE, "locale"),
)

SESSION_ENGINE = 'django.contrib.sessions.backends.file'

DIR_BLACKLIST = [
    'templates',
    'fnstatic',
    'middleware',
    'contrib',
    'common',
    'locale',
    'dojango',
    'tools',
    'api',
    'freeadmin',
    'static',
]
APP_MODULES = []

for entry in os.listdir(HERE):
    if entry in DIR_BLACKLIST:
        continue
    if os.path.isdir(os.path.join(HERE, entry)):
        APP_MODULES.append('freenasUI.%s' % entry)

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.staticfiles',
    'south',
    'dojango',
    'freenasUI.api',
    'freenasUI.freeadmin',
) + tuple(APP_MODULES)

BLACKLIST_NAV = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.staticfiles',
    'south',
    'dojango',
    'freeadmin',
)

FORCE_SCRIPT_NAME = ''

#TODO: Revisit me against cache posion attacks
#      Maybe offer as an option in the GUI
ALLOWED_HOSTS = ['*']

AUTH_USER_MODEL = 'account.bsdUsers'

SOUTH_TESTS_MIGRATE = False

FILE_UPLOAD_MAX_MEMORY_SIZE = 33554432
FILE_UPLOAD_TEMP_DIR = "/var/tmp/firmware/" 

# the site admins on every HTTP 500 error.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'simple': {
            'format': '[%(name)s:%(lineno)s] %(message)s'
        },
    },
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'class': 'django.utils.log.AdminEmailHandler',
            'filters': [],
        },
        'syslog': {
            'level': 'DEBUG',
            'class': 'freenasUI.freeadmin.handlers.SysLogHandler',
            'formatter': 'simple',
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': False,
        },
        '': {
            'handlers': ['syslog'],
            'level': 'DEBUG',
            'propagate': True,
        },
    }
}

# Django 1.5 requires it prior to run wsgi
SECRET_KEY = "." 

try:
    from local_settings import *
except:
    pass

#3 Updated by Suraj Ravichandran almost 6 years ago

Thank you for this.

Could you also paste local_settings.py file also in the same folder.

#4 Updated by William Grzybowski almost 6 years ago

This is not a FreeNAS problem AFAIK. Its probably just a cookie set in the same IP for a different version.

Can you try clearing your browser cookies?

#5 Updated by William Grzybowski almost 6 years ago

Also make sure you're not using any crazy proxies. Just direct access.

#6 Updated by Scott Bolte almost 6 years ago

I have tried two browsers, both with cookies for the FreeNAS FQDN URL (ala http://198.0.0.1) and without.

No proxies are involved. It's private, wired network.

Below is the local_settings.py file. I obfuscated the SECRET_KEY value. Let me know if you need the original value.

SECRET_KEY = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

FYI, with 9.1.1 I was running with HTTPS. However, with 9.3 I have yet to obtain the certificate to allow me to run. Without the GUI, I'm not sure how to do that.

#7 Updated by Suraj Ravichandran almost 6 years ago

That 2 settings in the file are what is preventing you from logging in via http.

I added them for #6916 but it relies on the database to be in sync so that is why you are having these problems.

Sorry about this.

If it is not too much too ask could you lend me your databse file so that I can try and put in a fix for this not happening in the future.

This database file will also help me find a workaround for your current system.

If you do not want to make it public then you could email it to me at .

I could also ssh (again if you permit me to do so) to your box and fix it for you

#8 Updated by Scott Bolte almost 6 years ago

With the database file implicated, I perused it using the top-notch Firefox extension SQLite Manager (https://addons.mozilla.org/en-us/firefox/addon/sqlite-manager/ for the extension, https://code.google.com/p/sqlite-manager/ for the code). I found the stg_guiprotocol field in the systems_settings table was https. I changed that to http. I also changed the stg_guiport field in the same table to be the standard 80. With those changes, the 9.1.1 configuration file imported into a fresh 9.3-RELEASE installed without any problem.

Let me know if you still need a copy of my 9.1.1 database for your root cause analysis. I can try to sanitize it, without altering it so much to mask the problem, and email it to you.

#9 Updated by Suraj Ravichandran almost 6 years ago

  • Status changed from 15 to Fix In Progress

Ah! got it.

Wait will get back with a fix if possible. (I had configured it such that if the protocol is "https" then it uses secure cookies).

This would work in the case that you had upgraded from 9.1.1 using an iso upgrade as I have put in code that grabs your 9.1.1 cert and passes it on to 9.3 in the database.

But since you just imported the config after doing a fresh install of 9.3-RELEASE no certificate was present and hence nginx did not go to https but django refused to send cookies on http.

No need for the database know.

#10 Updated by Suraj Ravichandran almost 6 years ago

On second thoughts I would like your database file sir....it should have had the certificate file within it if you had https mode enabled.

The only reason this would fail is the old config database not having the certificate file in it.

#11 Updated by Jan Willhaus almost 6 years ago

I hope you don't mind me chiming in. I experienced the same problem, updating v9.2.1.8 to 9.3. I had WebUI settings set to HTTPS-only.
As a temporary fix, I modified the database externally and changed the following entry:

system_settings.stg_guiprotocol = 'http'

After that I reset the server to factory defaults, logged in and uploaded the modified database.

#12 Updated by Suraj Ravichandran almost 6 years ago

@Jan Willhaus: Why would I mind user contribution (thats awesome!) so I will only say dont worry, your feedback and workaround are much appreciated.

So I think I had found the root cause for this (keyword being think!)

The config database actually does have the certificate but for some reason it is an invalid certificate (either it has expired or it uses 512-bit rsa key which we stopped supporting in 9.3-BETA and 9.3-RELEASE due to firefox blocking it or the cert is just invalid for some other reason).

What happens when the certificate is invalid is that when the nginx config generator is going through the database and finds http+https or https only option it first verifies whether the certificate is valid or not and if not then it lets the database value of the gui protocol to be whatever it is but instead just simply falls back to http and creates an alert in the gui which when you log-in to the now fallen-back http site shows up on the alert flashing light.

I was however not testing for this condition in the django conf creation script and thus still found the mode to be "https" and made the Credential Cookies secure and thus even though the WebGUI is falling-back to http mode since the login cookies do not support that mode your hosed!

I have made a small patch and applied it to my current system after replicating an environment similar to yours and it worked.

I am uploading the patch within this reply, if you could restore your configuration to factory apply the patch and re-try uploading the unaltered config that you initially tried it with and let me know of the results, then that would be highly appreciated.

Mentioning the process to do as follows:

1. Revert your patched config upload by executing a factory restore form the GUI---> System--->Factory Restore.

2. SSH into your freenas box, copy the patch included in this post to /etc/local/rc.d and from the same directory execute the below:
    patch -p1 < django.patch

3. Restart Django for the settings to take effect:
    patch -p1 < django.patch 

4. Upload original unaltered config from 9.1.1 (or whatever) and see the results.

#13 Updated by Suraj Ravichandran almost 6 years ago

Oops forgot the patch.... here

#14 Updated by Prasanth G almost 6 years ago

Suraj Ravichandran wrote:

Oops forgot the patch.... here

Had a similar issue. Tried the patch as instructed, but the "CSRF verification failed." issue persists. Any information I can pass on that would help?

Reason given for failure:
CSRF cookie not set.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:
Your browser is accepting cookies.
The view function uses RequestContext for the template, instead of Context.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.>

#15 Updated by J - almost 6 years ago

Did you try the patch as instructed or as you need to do to make it work? :-) Step 3 in the instructions is wrong and should be something more like

./django restart

In any case, with this patch I've moved forward one big step after having this issue when a 9.2.1.7 > 9.3 RELEASE upgrade messed up, so I started with a new install of 9.3 (taking the time to make my boot flash into a mirror - neat), and after I uploaded my original config (set to do HTTPS only and with a cert that came from CAcert and is probably considered substandard) being left with nginx listending only on port 80 and a django, per local_settings.py, that was looking for secured cookies only. Now I've got a working GUI on port 80 and I'm off to fix up my cert.

#16 Updated by Prasanth G almost 6 years ago

J - wrote:

Did you try the patch as instructed or as you need to do to make it work? :-) Step 3 in the instructions is wrong and should be something more like

./django restart

You're right I did restart django with "service django restart"

left with nginx listending only on port 80 and a django, per local_settings.py, that was looking for secured cookies only. Now I've got a working GUI on port 80 and I'm off to fix up my cert.

did you have to make changes to have it work with port 80? I'm relatively new to certs so I'm sure mine was inferior in the prior system.

#17 Updated by J - almost 6 years ago

After I restarted django I had nginx still listening only on port 80, a config that called for only using HTTPS, and an alert that the web gui had fallen back to using HTTP due to lack of valid cert. The big, and only difference I noticed, was that django's local_settings.py file no longer had the two lines calling for use of secure cookies only.

At that point the GUI worked for me on port 80.

My former cert did not show up in the list of available certificates at all.

I then upload a "real" cert (luckily I had a wildcard available that works, otherwise I'd be rather put out about the way FreeNAS is trying to be a nanny about my use of CAcert cert's for internal machines), called for use of that cert in System General, and left the setting there as HTTPS only. After I saved that, I was redirected to https://IPAddress, with the expected whining about the cert name not matching. When I manually told my browser to go to HTTPS://FQDN, all appears to be well.

I could, I rather strongly suspect, used either an internally generated cert, or set the GUI to use HTTP, as alternative solutions. Neither of those I tried.

#18 Updated by Suraj Ravichandran almost 6 years ago

  • Target version set to Unspecified

@J service django restart will work too! its made to be so by us!

I did not quite get your last post .... so the patch if it works should detect that a valid cert was absent and make django aware that the cookies should NOT be sent securely and then those two cookie related lines in the local_setting.py will vanish.

This was what the patch was meant to do and it looks like it worked.

Can you check your `former` cert for validity, also i was suggest just importing your former cert into the new cert manager UI directly.

Please get back if I was not clear enough or you need more help.

Thanks

#19 Updated by J - almost 6 years ago

Suraj Ravichandran wrote:

@J service django restart will work too! its made to be so by us!

Of course, and I never said that didn't work. However, "patch p1 < django.patch" does not restart django, as you mistakenly stated. Read what you wrote instead of what you meant to write. ;)

I did not quite get your last post .... so the patch if it works should detect that a valid cert was absent and make django aware that the cookies should NOT be sent securely and then those two cookie related lines in the local_setting.py will vanish.

This was what the patch was meant to do and it looks like it worked.

It did work. That is precisely what happened; I even looked at local_settings.py to confirm.

Can you check your `former` cert for validity, also i was suggest just importing your former cert into the new cert manager UI directly.

That is a fool's errand unless you define what you mean by validity. I couldn't find anything in the manual about that, not that I looked very hard. Frankly some of the new CA / Cert functionality seems to be a bit half-baked and/or not fully documented still. For example, from section 5.9 of the manual: "If your organization already has a CA, you can import the CA’s certificate and key. Click the “Import CA” button to open the configuration screen shown in Figure 5.9b." If I were the security officer in charge of an organizational CA, I can't imagine the circumstances under which I'd release the key to the admin of some random NAS box. That pretty much would defeat the purpose of having an organizational CA for any organization with IT staff greater than 1. On the other hand, it may just be a documentation flaw, in that the key and secret fields are not marked mandatory, and this dialog also serves to simply add a new trusted root certificate. In which case the manual should probably mention that.

Please get back if I was not clear enough or you need more help.

Given that I had an existing wildcard, "real" (i.e., issued by CA whose root cert is widely distributed) cert that I can use, everything works. If I needed to get the previous cert from CAcert, which meets fewer definitions of validity, working, I might still be having issues.

Actually, I'm curious enough to experiment just a bit. I'll let you know if I find anything interesting.

#20 Updated by Scott Bolte almost 6 years ago

I applied the patch, uploaded the original 9.1.1 configuration file, and the CSRF file once again occurred.

I checked the /etc/local/rc.d/django file and it was back to the prior contents. I presume that file, actually that entire directory, is regenerated either on reboot or as part of the configuration upload. That wiped out the patch.

#21 Updated by Scott Bolte almost 6 years ago

Vanna, I need to buy a vowel. Instead of "filed once again" I meant to write "failed once again."

#22 Updated by Prasanth G almost 6 years ago

Scott Bolte wrote:

I applied the patch, uploaded the original 9.1.1 configuration file, and the CSRF file once again occurred.

I checked the /etc/local/rc.d/django file and it was back to the prior contents. I presume that file, actually that entire directory, is regenerated either on reboot or as part of the configuration upload. That wiped out the patch.

Same thing happened to me, so instead I just applied the patch after the upload of configuration file. I regained http access, after which I created a new internal certificate and used that for https access. Server seems to be running fine with full GUI access. My only concern might be will all this stick on a restart of the server.

#23 Updated by Suraj Ravichandran almost 6 years ago

4905b52c0200093ba55012b5bc7e69b17deb6860

It should be available in the next SU (software Update) and at that point it will be in the system and stay in there (no need to worry about stuff getting deleted).

I am also trying to get a command line (freenas actual console from the box runnig freenas -- like with a monitor and keyboard attached to that box).option that would let you revert to http on port 80 in the scenario that some cert related problems hosed your GUI.

Sorry for this everyone! But thanks for the quick feedback, such a community response is truly amazing!

#24 Updated by Suraj Ravichandran almost 6 years ago

  • Status changed from Fix In Progress to Ready For Release

#25 Updated by Scott Bolte almost 6 years ago

Just applied the latest 9.3 RELEASE update (see below), the update with the fix to 7049, and the problem when loading a 9.1.1 configuration file with an invalid SSL certificate remains.

Upgrade: base-os-9.3-STABLE-8bf5974-3b4abc3-109b881 -> base-os-9.3-STABLE-3a9da8b-3b4abc3-109b881
Upgrade: FreeNASUI-9.3-STABLE-8bf5974-3b4abc3-109b881 -> FreeNASUI-9.3-STABLE-3a9da8b-3b4abc3-109b881

Here are the steps I took:

  1. Upgraded from FreeNAS-9.3-STABLE-201412091831 to FreeNAS-9.3-STABLE-201412142325.
  2. Uploaded the 9.1.1 configuration file with an SSL certificate that is no longer considered valid. The protocol setting was also set to HTTPS. System accepted the upload, rebooted twice as it is supposed to do.
  3. When prompted by the Web GUI to set the root password I tried and was rejected.
  4. Set the root password from the console.
  5. Logged in on the Web GUI using the newly set root password and got the old CSRF failure page.

Observations of the system:

  • The modified test in /etc/local/rc.d/django includes the check for /tmp/alert_invalid_ssl_nginx
  • The file /tmp/alert_invalid_ssl_nginx is present.
  • The SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE keys are both set to True in /usr/local/www.freenasUS/local_settings.py

I removed the two problem cookies from local_settings.py, ran (/etc/local/rc.d/django restart), and then was able to log into the Web GUI again.

Final observations:

  • After I was able to log in to the Web GUI, the System -> General -> Protocol field is set to HTTPS.
  • I did not install from ISO as I did with prior tests. Not sure if that left crud in the local_settings.py file or somewhere else that undermined the expected processing.

#26 Updated by Jordan Hubbard almost 6 years ago

  • Status changed from Ready For Release to Resolved

#27 Updated by Michael Monreal almost 6 years ago

I ran into the same problem ("CSRF verification failed.") when trying to import my FreeNAS 9.2.1.8 config into a newly installed (because upgrade broke completely...) FreeNAS 9.3. I installed all additional updates before importing, the update to fix this bug was included. Are there any additional steps or do I need to file a new bug?

#28 Updated by Joseph Scafide almost 6 years ago

I hade the exact same issue as of last night.

I ran into the same problem ("CSRF verification failed.") when trying to import my FreeNAS 9.2.1.8 config into a newly installed (because upgrade broke completely...) FreeNAS 9.3. I installed all additional updates before importing, the update to fix this bug was included. Are there any additional steps or do I need to file a new bug?

#29 Updated by Joseph Scafide almost 6 years ago

Same version 9.2.1.8 same problem broke during upgrade, ran iso install and loaded config and now doomed with CSRF try to change passwd via sia and from monitor no dice. Anyhelp would be great, currently switching to beta and then try to import comfig will post back if I can get in to webgui

#30 Updated by Joseph Scafide almost 6 years ago

did it "by hand". I had to do it twice because the update erase it.
Like AlexF explain:

The patch is changing following line in /etc/local/rc.d/django
from:
if [ ${webguiproto} = "https" ]; then
to:
if [ ${webguiproto} = "https" -a ! -f /tmp/alert_invalid_ssl_nginx ]; then

Once modified and django restarted using "./django restart" (needing twice for some reason) I could login using HTTP.

As per 5.9. CAs, I created internal CA (System->CA) and then internal Certificate (System->Certificates) referencing forementioned internal CA; then changed Protocol to HTTPS (System ->General : Protocol) and rebooted.

Now can login using HTTPS. (Browser will complain because certificates is signed by non-trusted CA - you'll need to tell it to create an exception).

You can edit it with the shell directly on your NAS, or by ssh.
Follow ALL the steps:
1. log in (ssh or shell)
2. type " edit /etc/local/rc.d/django "
3. change the text as above "https" ]; then to "https" -a ! -f /tmp/alert_invalid_ssl_nginx ]; then
4. save it esc+enter
5. type " cd /etc/local/rc.d/ "
6. type " ./django restart "
7. type " ./django restart " yes twice
8. log in your nas http://you.local.nas.address
9. go to system
10. system ->CA create a CA
11. system-> certificates create a certificate
12. system -> general chose the certificate you just did

#31 Updated by Michael De Vogelaer almost 6 years ago

ran into the same issue upgrading from 9.2.1.7 to 9.3

downloaded today's release (17/12) and upgraded to latest but still ran into the bug.

#32 Updated by Michael Monreal almost 6 years ago

Joseph Scafide wrote:

did it "by hand".

Following your post I was able to make it work, too. Thanks!

#33 Updated by Michael De Vogelaer over 5 years ago

any updates on this?
I'd like (ideally) some way to not tinker with ssh and the system automaticly booting in freenas, unless ofc you're going to tell me now that thats never going to happen.

#34 Updated by Joseph Scafide over 5 years ago

Bump. I am curious as well! Seems like a major issue that many will not solve.

Michael De Vogelaer wrote:

any updates on this?
I'd like (ideally) some way to not tinker with ssh and the system automaticly booting in freenas, unless ofc you're going to tell me now that thats never going to happen.

#35 Updated by Suraj Ravichandran over 5 years ago

  • Status changed from Resolved to Screened

I am sorry but had overlooked some other details in the fix I included for this......

Working on the correct fix as we speak!

#36 Updated by Suraj Ravichandran over 5 years ago

  • Category set to 118
  • Status changed from Screened to Ready For Release

This is fixed and will be available in the next Software Update(SU) for the stable train.

#37 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Ready For Release to Resolved

#38 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF