Hi everyone,
I have some troubles to log in my Web UI. I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http:// with a domain name but have not set up https?
If so, have you read the notes on CSRF support: https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
Yes i'm using localhost and i'm using simple Django accounts.
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http:// with a domain name but have not set up https?
If so, have you read the notes on CSRF support:
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends me back
to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http:// with a domain name but have not set up https?
If so, have you read the notes on CSRF support: https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
I cleaned up my browser cookies and now I'm getting the CSRF Verification Failed error, even with :
"CSRF_COOKIE_SECURE": false,"SESSION_COOKIE_SECURE": false
in /etc/lava-server/settings.conf I don't understand, I made no modifications.
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org
wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org
wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http:// with a domain name but have not set up https?
If so, have you read the notes on CSRF support:
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends me
back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Tue, 13 Nov 2018 at 15:22, Axel Lebourhis axel.lebourhis@linaro.org wrote:
I cleaned up my browser cookies and now I'm getting the CSRF Verification Failed error, even with :
"CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false
in /etc/lava-server/settings.conf
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This isn't about browser cookies - some browsers cache authentication separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http:// with a domain name but have not set up https?
If so, have you read the notes on CSRF support: https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org wrote:
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache authentication
separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I tried on both Firefox and Chrome, nothing new.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in this file. I modified directly the common.py file to set the default value to False. Now I don't have the CSRF error anymore, but I'm still not logged in, back to starting point.
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org
wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org
wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org
wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
Hi everyone,
I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http://
with
a domain name but have not set up https?
If so, have you read the notes on CSRF support:
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
I type the good password and username and then the website sends
me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
Best regards, Axel Le Bourhis _______________________________________________ Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
I fixed the issue by "hard" coding the follwing lines in /usr/lib/python3/dist-packages/lava_server/settings/common.py
CSRF_COOKIE_SECURE = FalseSESSION_COOKIE_SECURE = False
It's like it doesn't take in count my /etc/lava-server/settings.conf file.
Regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org wrote:
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache authentication
separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I tried on both Firefox and Chrome, nothing new.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in this file. I modified directly the common.py file to set the default value to False. Now I don't have the CSRF error anymore, but I'm still not logged in, back to starting point.
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org
wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams <
neil.williams@linaro.org> wrote:
On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
> > Hi everyone, > > I have some troubles to log in my Web UI.
Are you using http://localhost ? or are you trying to use http://
with
a domain name but have not set up https?
If so, have you read the notes on CSRF support:
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
Have you configured LDAP or are you using simple Django accounts?
> I type the good password and username and then the website sends
me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
> > Best regards, > Axel Le Bourhis > _______________________________________________ > Lava-users mailing list > Lava-users@lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 15 Nov 2018 at 08:35, Axel Lebourhis axel.lebourhis@linaro.org wrote:
I fixed the issue by "hard" coding the follwing lines in /usr/lib/python3/dist-packages/lava_server/settings/common.py
CSRF_COOKIE_SECURE = False SESSION_COOKIE_SECURE = False
It's like it doesn't take in count my /etc/lava-server/settings.conf file.
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Possibly try adding "CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
You can also use the developer shell to load the settings and see what has actually been set.
$ sudo lava-server manage shell
from django.conf import settings settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary. Don't be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org wrote:
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache authentication separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I tried on both Firefox and Chrome, nothing new.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in this file. I modified directly the common.py file to set the default value to False. Now I don't have the CSRF error anymore, but I'm still not logged in, back to starting point.
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login without https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote: > > On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote: > > > > Hi everyone, > > > > I have some troubles to log in my Web UI. > > Are you using http://localhost ? or are you trying to use http:// with > a domain name but have not set up https? > > If so, have you read the notes on CSRF support: > https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig... > > Have you configured LDAP or are you using simple Django accounts? > > > I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs. > > > > Best regards, > > Axel Le Bourhis > > _______________________________________________ > > Lava-users mailing list > > Lava-users@lists.lavasoftware.org > > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > -- > > Neil Williams > ============= > neil.williams@linaro.org > http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 15 Nov 2018 at 09:46, Neil Williams neil.williams@linaro.org wrote:
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping
correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Yes I just wanted to check if my config was actually took in count or not. I didn't know I could check this through the developer shell, will do next time.
Possibly try adding
"CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
I added this line and I removed a line which was about LXC_PATH. Maybe this was the root of the problem, leading to an error when reading the settings and making django use the default settings. But now it works fine, so thank you for that.
You can also use the developer shell to load the settings and see what has actually been set.
$ sudo lava-server manage shell
from django.conf import settings settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary. Don't be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Thank you for this information, I will use this tool now to check my settings.
Best regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org
wrote:
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache authentication separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I tried on both Firefox and Chrome, nothing new.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in
this file.
I modified directly the common.py file to set the default value to
False.
Now I don't have the CSRF error anymore, but I'm still not logged in,
back to starting point.
On Tue, 13 Nov 2018 at 16:16, Neil Williams <
neil.williams@linaro.org> wrote:
On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
> > Yes i'm using localhost and i'm using simple Django accounts.
In which case you need to set the CSRF settings to allow login
without
https as in the link I posted.
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
> > On Tue, 13 Nov 2018 at 16:02, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
>> > >> > Hi everyone, >> > >> > I have some troubles to log in my Web UI. >> >> Are you using http://localhost ? or are you trying to use
http:// with
>> a domain name but have not set up https? >> >> If so, have you read the notes on CSRF support: >>
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
>> >> Have you configured LDAP or are you using simple Django accounts? >> >> > I type the good password and username and then the website
sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
>> > >> > Best regards, >> > Axel Le Bourhis >> > _______________________________________________ >> > Lava-users mailing list >> > Lava-users@lists.lavasoftware.org >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> >> Neil Williams >> ============= >> neil.williams@linaro.org >> http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 15 Nov 2018 at 09:20, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Thu, 15 Nov 2018 at 09:46, Neil Williams neil.williams@linaro.org wrote:
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Yes I just wanted to check if my config was actually took in count or not. I didn't know I could check this through the developer shell, will do next time.
Possibly try adding "CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
I added this line and I removed a line which was about LXC_PATH. Maybe this was the root of the problem, leading to an error when reading the settings and making django use the default settings.
If that was the case, it's something that should be investigated to see if it can be detected .
The other tool to use in these situations (I keep forgetting to recommend it) is:
lava-server manage check --deploy
Please could you file an issue on https://git.lavasoftware.org/lava/lava/issues ? The issue should investigate what Django does if there are errors in /etc/lava-server/settings.conf and how those errors can be detected with lava-server manage check --deploy
But now it works fine, so thank you for that.
Thanks. I am always concerned when users resort to changing the defaults in common.py - there is clearly a problem affecting their system and it is never clear where the problem lies, only that changing common.py is only a temporary fix. Authentication backends are very opaque - whilst it's true that this avoids leaking details of valid authentications, it is common to find a lack of useful debug information in the same code. We hand off this part to Django, so we don't get the chance to add debug during authentication. If we can find a way to report that /etc/lava-server/settings.conf is invalid or has been ignored for some reason, that should help others with their problems.
You can also use the developer shell to load the settings and see what has actually been set.
$ sudo lava-server manage shell
from django.conf import settings settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary. Don't be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Thank you for this information, I will use this tool now to check my settings.
Best regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org wrote:
When changing /etc/lava-server/settings.conf ensure that the gunicorn service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache authentication separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need to be closed.
I tried on both Firefox and Chrome, nothing new.
I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in this file. I modified directly the common.py file to set the default value to False. Now I don't have the CSRF error anymore, but I'm still not logged in, back to starting point.
On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org wrote: > > On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote: > > > > Yes i'm using localhost and i'm using simple Django accounts. > > In which case you need to set the CSRF settings to allow login without > https as in the link I posted. > > https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig... > > > > > On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote: > >> > >> On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote: > >> > > >> > Hi everyone, > >> > > >> > I have some troubles to log in my Web UI. > >> > >> Are you using http://localhost ? or are you trying to use http:// with > >> a domain name but have not set up https? > >> > >> If so, have you read the notes on CSRF support: > >> https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig... > >> > >> Have you configured LDAP or are you using simple Django accounts? > >> > >> > I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs. > >> > > >> > Best regards, > >> > Axel Le Bourhis > >> > _______________________________________________ > >> > Lava-users mailing list > >> > Lava-users@lists.lavasoftware.org > >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users > >> > >> > >> > >> -- > >> > >> Neil Williams > >> ============= > >> neil.williams@linaro.org > >> http://www.linux.codehelp.co.uk/ > > > > -- > > Neil Williams > ============= > neil.williams@linaro.org > http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 15 Nov 2018 at 10:33, Neil Williams neil.williams@linaro.org wrote:
On Thu, 15 Nov 2018 at 09:20, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Thu, 15 Nov 2018 at 09:46, Neil Williams neil.williams@linaro.org
wrote:
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Yes I just wanted to check if my config was actually took in count or
not. I didn't know I could check this through
the developer shell, will do next time.
Possibly try adding "CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
I added this line and I removed a line which was about LXC_PATH. Maybe
this was the root of the problem,
leading to an error when reading the settings and making django use the
default settings.
If that was the case, it's something that should be investigated to see if it can be detected .
The other tool to use in these situations (I keep forgetting to recommend it) is:
lava-server manage check --deploy
Please could you file an issue on https://git.lavasoftware.org/lava/lava/issues ? The issue should investigate what Django does if there are errors in /etc/lava-server/settings.conf and how those errors can be detected with lava-server manage check --deploy
I double checked, trying to recreate the problem by readding the LXC_PATH line and removing the line "CSRF_COOKIE_HTTPONLY": false. Everything is still working fine... I made sure the settings was took in count by resetting the CSRF verification to true, and it is. Also checked with lava-server manage check --deploy, everything is how it is expected. So, I'm not sure what this was about... Surely an issue with my environment. Do you still want me to submit an issue ? I'm not sure it would be relevant as the issue seems to be linked to random environment issue (maybe a gunicorn process as you suggested before). If so, do I have to create an account or do something ? Tried to log in with my Linaro account but didn't work.
But now it works fine, so thank you for that.
Thanks. I am always concerned when users resort to changing the defaults in common.py - there is clearly a problem affecting their system and it is never clear where the problem lies, only that changing common.py is only a temporary fix. Authentication backends are very opaque - whilst it's true that this avoids leaking details of valid authentications, it is common to find a lack of useful debug information in the same code. We hand off this part to Django, so we don't get the chance to add debug during authentication. If we can find a way to report that /etc/lava-server/settings.conf is invalid or has been ignored for some reason, that should help others with their problems.
Yes this would be useful to put this kind of debug in the lava-master log (or whatever you prefer) because this is the first thing I checked and no information were provided.
You can also use the developer shell to load the settings and see what has actually been set.
$ sudo lava-server manage shell
from django.conf import settings settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary. Don't be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Thank you for this information, I will use this tool now to check my
settings.
Best regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams <
neil.williams@linaro.org> wrote:
When changing /etc/lava-server/settings.conf ensure that the
gunicorn
service is restarted
$ sudo service lava-server-gunicorn restart
This has been done.
This isn't about browser cookies - some browsers cache
authentication
separately to cookies and sometimes it just needs a separate browser to get passed an initial failure. e..g use firefox instead of chrome and vice versa. Also it can be that all windows of the browser need
to
be closed.
I tried on both Firefox and Chrome, nothing new.
> I don't understand, I made no modifications.
Unless you use https:// you need to modify at least /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in
this file.
I modified directly the common.py file to set the default value to
False.
Now I don't have the CSRF error anymore, but I'm still not logged
in, back to starting point.
> On Tue, 13 Nov 2018 at 16:16, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
>> > >> > Yes i'm using localhost and i'm using simple Django accounts. >> >> In which case you need to set the CSRF settings to allow login
without
>> https as in the link I posted. >> >>
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
>> >> > >> > On Tue, 13 Nov 2018 at 16:02, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> >> >> On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
>> >> > >> >> > Hi everyone, >> >> > >> >> > I have some troubles to log in my Web UI. >> >> >> >> Are you using http://localhost ? or are you trying to use
http:// with
>> >> a domain name but have not set up https? >> >> >> >> If so, have you read the notes on CSRF support: >> >>
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
>> >> >> >> Have you configured LDAP or are you using simple Django
accounts?
>> >> >> >> > I type the good password and username and then the website
sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
>> >> > >> >> > Best regards, >> >> > Axel Le Bourhis >> >> > _______________________________________________ >> >> > Lava-users mailing list >> >> > Lava-users@lists.lavasoftware.org >> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> >> >> >> >> -- >> >> >> >> Neil Williams >> >> ============= >> >> neil.williams@linaro.org >> >> http://www.linux.codehelp.co.uk/ >> >> >> >> -- >> >> Neil Williams >> ============= >> neil.williams@linaro.org >> http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Thu, 15 Nov 2018 at 10:06, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Thu, 15 Nov 2018 at 10:33, Neil Williams neil.williams@linaro.org wrote:
On Thu, 15 Nov 2018 at 09:20, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Thu, 15 Nov 2018 at 09:46, Neil Williams neil.williams@linaro.org wrote:
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Yes I just wanted to check if my config was actually took in count or not. I didn't know I could check this through the developer shell, will do next time.
Possibly try adding "CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
I added this line and I removed a line which was about LXC_PATH. Maybe this was the root of the problem, leading to an error when reading the settings and making django use the default settings.
If that was the case, it's something that should be investigated to see if it can be detected .
The other tool to use in these situations (I keep forgetting to recommend it) is:
lava-server manage check --deploy
Please could you file an issue on https://git.lavasoftware.org/lava/lava/issues ? The issue should investigate what Django does if there are errors in /etc/lava-server/settings.conf and how those errors can be detected with lava-server manage check --deploy
I double checked, trying to recreate the problem by readding the LXC_PATH line and removing the line "CSRF_COOKIE_HTTPONLY": false. Everything is still working fine... I made sure the settings was took in count by resetting the CSRF verification to true, and it is. Also checked with lava-server manage check --deploy, everything is how it is expected. So, I'm not sure what this was about... Surely an issue with my environment. Do you still want me to submit an issue ? I'm not sure it would be relevant as the issue seems to be linked to random environment issue (maybe a gunicorn process as you suggested before).
It would still useful if lava-server manage check --deploy could report that the settings reported from Django don't match /etc/lava-server/settings.conf or if /etc/lava-server/settings.conf has some kind of syntax error. So, yes, an issue would be good.
If so, do I have to create an account or do something ? Tried to log in with my Linaro account but didn't work.
If you have a GitHub account, click the GitHub icon and log in that way. If not, please create a new account. It will be useful when there are upstream changes you wish to contribute from your testing or devices. e.g. a documentation update for identifying and fixing problems with login.
But now it works fine, so thank you for that.
Thanks. I am always concerned when users resort to changing the defaults in common.py - there is clearly a problem affecting their system and it is never clear where the problem lies, only that changing common.py is only a temporary fix. Authentication backends are very opaque - whilst it's true that this avoids leaking details of valid authentications, it is common to find a lack of useful debug information in the same code. We hand off this part to Django, so we don't get the chance to add debug during authentication. If we can find a way to report that /etc/lava-server/settings.conf is invalid or has been ignored for some reason, that should help others with their problems.
Yes this would be useful to put this kind of debug in the lava-master log (or whatever you prefer) because this is the first thing I checked and no information were provided.
You can also use the developer shell to load the settings and see what has actually been set.
$ sudo lava-server manage shell
> from django.conf import settings > settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary. Don't be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Thank you for this information, I will use this tool now to check my settings.
Best regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Tue, 13 Nov 2018 at 16:35, Neil Williams neil.williams@linaro.org wrote: > > > When changing /etc/lava-server/settings.conf ensure that the gunicorn > service is restarted > > > $ sudo service lava-server-gunicorn restart >
This has been done.
> This isn't about browser cookies - some browsers cache authentication > separately to cookies and sometimes it just needs a separate browser > to get passed an initial failure. e..g use firefox instead of chrome > and vice versa. Also it can be that all windows of the browser need to > be closed.
I tried on both Firefox and Chrome, nothing new.
> > > > I don't understand, I made no modifications. > > Unless you use https:// you need to modify at least > /etc/lava-server/settings.conf
The configuration needed to use http://localhost was already set in this file. I modified directly the common.py file to set the default value to False. Now I don't have the CSRF error anymore, but I'm still not logged in, back to starting point.
> > > On Tue, 13 Nov 2018 at 16:16, Neil Williams neil.williams@linaro.org wrote: > >> > >> On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis axel.lebourhis@linaro.org wrote: > >> > > >> > Yes i'm using localhost and i'm using simple Django accounts. > >> > >> In which case you need to set the CSRF settings to allow login without > >> https as in the link I posted. > >> > >> https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig... > >> > >> > > >> > On Tue, 13 Nov 2018 at 16:02, Neil Williams neil.williams@linaro.org wrote: > >> >> > >> >> On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis axel.lebourhis@linaro.org wrote: > >> >> > > >> >> > Hi everyone, > >> >> > > >> >> > I have some troubles to log in my Web UI. > >> >> > >> >> Are you using http://localhost ? or are you trying to use http:// with > >> >> a domain name but have not set up https? > >> >> > >> >> If so, have you read the notes on CSRF support: > >> >> https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig... > >> >> > >> >> Have you configured LDAP or are you using simple Django accounts? > >> >> > >> >> > I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs. > >> >> > > >> >> > Best regards, > >> >> > Axel Le Bourhis > >> >> > _______________________________________________ > >> >> > Lava-users mailing list > >> >> > Lava-users@lists.lavasoftware.org > >> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> Neil Williams > >> >> ============= > >> >> neil.williams@linaro.org > >> >> http://www.linux.codehelp.co.uk/ > >> > >> > >> > >> -- > >> > >> Neil Williams > >> ============= > >> neil.williams@linaro.org > >> http://www.linux.codehelp.co.uk/ > > > > -- > > Neil Williams > ============= > neil.williams@linaro.org > http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
Ok I submitted the issue #162 : https://git.lavasoftware.org/lava/lava/issues/162
Thanks for the help.
On Thu, 15 Nov 2018 at 11:11, Neil Williams neil.williams@linaro.org wrote:
On Thu, 15 Nov 2018 at 10:06, Axel Lebourhis axel.lebourhis@linaro.org wrote:
On Thu, 15 Nov 2018 at 10:33, Neil Williams neil.williams@linaro.org
wrote:
On Thu, 15 Nov 2018 at 09:20, Axel Lebourhis axel.lebourhis@linaro.org
wrote:
On Thu, 15 Nov 2018 at 09:46, Neil Williams neil.williams@linaro.org
wrote:
There is a separate problem here, on your local setup. Avoid making changes to common.py which cannot go upstream because every package update will assert the upstream version without any regard to your change.
It's possible you have a gunicorn process which isn't stopping correcltly, possibly due to an earlier misconfiguration. It's also possible you may need to restart Apache.
What you have at the moment isn't a fix, it's only a step to work out the actual fix.
Yes I just wanted to check if my config was actually took in count or
not. I didn't know I could check this through
the developer shell, will do next time.
Possibly try adding "CSRF_COOKIE_HTTPONLY": false,
in /etc/lava-server/settings.conf
I added this line and I removed a line which was about LXC_PATH.
Maybe this was the root of the problem,
leading to an error when reading the settings and making django use
the default settings.
If that was the case, it's something that should be investigated to see if it can be detected .
The other tool to use in these situations (I keep forgetting to recommend it) is:
lava-server manage check --deploy
Please could you file an issue on https://git.lavasoftware.org/lava/lava/issues ? The issue should investigate what Django does if there are errors in /etc/lava-server/settings.conf and how those errors can be detected with lava-server manage check --deploy
I double checked, trying to recreate the problem by readding the
LXC_PATH line and removing the line "CSRF_COOKIE_HTTPONLY": false.
Everything is still working fine... I made sure the settings was took in
count by resetting the CSRF verification to true, and it is.
Also checked with lava-server manage check --deploy, everything is how
it is expected. So, I'm not sure what this was about... Surely an issue with my environment.
Do you still want me to submit an issue ? I'm not sure it would be
relevant as the issue seems to be linked to random environment issue (maybe a gunicorn process
as you suggested before).
It would still useful if lava-server manage check --deploy could report that the settings reported from Django don't match /etc/lava-server/settings.conf or if /etc/lava-server/settings.conf has some kind of syntax error. So, yes, an issue would be good.
If so, do I have to create an account or do something ? Tried to log in
with my Linaro account but didn't work.
If you have a GitHub account, click the GitHub icon and log in that way. If not, please create a new account. It will be useful when there are upstream changes you wish to contribute from your testing or devices. e.g. a documentation update for identifying and fixing problems with login.
But now it works fine, so thank you for that.
Thanks. I am always concerned when users resort to changing the defaults in common.py - there is clearly a problem affecting their system and it is never clear where the problem lies, only that changing common.py is only a temporary fix. Authentication backends are very opaque - whilst it's true that this avoids leaking details of valid authentications, it is common to find a lack of useful debug information in the same code. We hand off this part to Django, so we don't get the chance to add debug during authentication. If we can find a way to report that /etc/lava-server/settings.conf is invalid or has been ignored for some reason, that should help others with their problems.
Yes this would be useful to put this kind of debug in the lava-master
log (or whatever you prefer)
because this is the first thing I checked and no information were
provided.
You can also use the developer shell to load the settings and see
what
has actually been set.
$ sudo lava-server manage shell
>> from django.conf import settings >> settings.CSRF_COOKIE_SECURE
False
Again, avoid making changes here, those would only be temporary.
Don't
be tempted to do much more than check the settings in the developer shell - it is massively powerful and can easily trash your instance. It is a useful tool, when used with caution.
https://master.lavasoftware.org/static/docs/v2/development.html#developer-ac...
Thank you for this information, I will use this tool now to check my
settings.
Best regards, Axel
On Tue, 13 Nov 2018 at 16:45, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
> > > > On Tue, 13 Nov 2018 at 16:35, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> >> When changing /etc/lava-server/settings.conf ensure that the
gunicorn
>> service is restarted >> >> >> $ sudo service lava-server-gunicorn restart >> > > This has been done. > >> This isn't about browser cookies - some browsers cache
authentication
>> separately to cookies and sometimes it just needs a separate
browser
>> to get passed an initial failure. e..g use firefox instead of
chrome
>> and vice versa. Also it can be that all windows of the browser
need to
>> be closed. > > > I tried on both Firefox and Chrome, nothing new. > >> >> >> > I don't understand, I made no modifications. >> >> Unless you use https:// you need to modify at least >> /etc/lava-server/settings.conf > > > The configuration needed to use http://localhost was already set
in this file.
> I modified directly the common.py file to set the default value
to False.
> Now I don't have the CSRF error anymore, but I'm still not logged
in, back to starting point.
> > >> >> > On Tue, 13 Nov 2018 at 16:16, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> >> >> On Tue, 13 Nov 2018 at 15:04, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
>> >> > >> >> > Yes i'm using localhost and i'm using simple Django
accounts.
>> >> >> >> In which case you need to set the CSRF settings to allow
login without
>> >> https as in the link I posted. >> >> >> >>
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
>> >> >> >> > >> >> > On Tue, 13 Nov 2018 at 16:02, Neil Williams <
neil.williams@linaro.org> wrote:
>> >> >> >> >> >> On Tue, 13 Nov 2018 at 14:55, Axel Lebourhis <
axel.lebourhis@linaro.org> wrote:
>> >> >> > >> >> >> > Hi everyone, >> >> >> > >> >> >> > I have some troubles to log in my Web UI. >> >> >> >> >> >> Are you using http://localhost ? or are you trying to use
http:// with
>> >> >> a domain name but have not set up https? >> >> >> >> >> >> If so, have you read the notes on CSRF support: >> >> >>
https://master.lavasoftware.org/static/docs/v2/installing_on_debian.html?hig...
>> >> >> >> >> >> Have you configured LDAP or are you using simple Django
accounts?
>> >> >> >> >> >> > I type the good password and username and then the
website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs.
>> >> >> > >> >> >> > Best regards, >> >> >> > Axel Le Bourhis >> >> >> > _______________________________________________ >> >> >> > Lava-users mailing list >> >> >> > Lava-users@lists.lavasoftware.org >> >> >> >
https://lists.lavasoftware.org/mailman/listinfo/lava-users
>> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Neil Williams >> >> >> ============= >> >> >> neil.williams@linaro.org >> >> >> http://www.linux.codehelp.co.uk/ >> >> >> >> >> >> >> >> -- >> >> >> >> Neil Williams >> >> ============= >> >> neil.williams@linaro.org >> >> http://www.linux.codehelp.co.uk/ >> >> >> >> -- >> >> Neil Williams >> ============= >> neil.williams@linaro.org >> http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
lava-users@lists.lavasoftware.org