On Mon, Jan 30, 2017 at 1:45 PM, Stephen McDonald <[email protected]> wrote:
> > > On Mon, Jan 30, 2017 at 3:42 AM, CJWalther <[email protected]> wrote: > >> Hi >> >> On Sunday, January 29, 2017 at 3:40:46 AM UTC+1, Akhlaq Rao wrote: >>> >>> Sorry I miss interpreted, did you select the site while creating this >>> user? >>> >>> >> I just tried with adding yet another user: While creating it in the first >> step there is no site to select. This comes in a second step while >> configuring the user account. There there is only one site entry ( >> 127.0.0.1:8000) and selecting, meaning highlighting it, not only doesn't >> change anything but also is kind of counter-intuitive... >> > > You're right it's not very intuitive. Like Ryne said we recently added a > warning message when you edit the user without selecting site permissions. > Perhaps we could also make the site selection step automatic when only one > site exists. > > As for your issue though, I can't reproduce it. I create a user without > selecting the site, and they get the same error as you do. Then after > selecting the (one and only) site for that user, they can then access the > (empty looking, sans individual edit/group permissions being given) admin > area. > > To go into a bit more detail on the common mistake Ryne mentioned - be > sure to *actually select* the site. It's a multi-select list that contains > one or more sites in it, their presence in the form field merely indicates > that they're a site that's available to grant permission to - you still > need to select each (and in your case only) one. > > If you've certainly definitely absolutely 100% done that, and triple > checked that your selection persisted when you saved the user by going to > the edit view again and checking it, then I can only suggest that the host > for the site isn't matching the host being used to access the site when > trying to log into the admin area. If you're developing locally, you're > probably using a port number other than 80, so the host in the site record > should contain that too, eg 127.0.0.1:8000 and not just 127.0.0.1. Also > note that "localhost" and "127.0.0.1" are not the same thing for this > purpose - the site checking code doesn't perform DNS lookups, it just > literally compares the host header (of the browser requesting the site) to > the value you entered into the admin for the site record. (Note that all > this should be done for you automatically during development if you > followed the documented setup instructions.) > > If you're not doing the standard local development setup, and are using a > separate web server to proxy requests to the Django app, be sure it's also > configured correctly to pass on the HTTP_HOST header. If you have say nginx > serving on mysite.com and proxying requests to the Django app listening > on 127.0.0.1:8000, the host header the Django app will see will be > 127.0.0.1:8000 if nginx doesn't pass on the correct host header ( > mysite.com). > BTW a quick trick for checking my last point is adding the following line to a template: http host is: {{ request.META.HTTP_HOST }} ( https://docs.djangoproject.com/en/1.10/ref/request-response/#django.http.HttpRequest.META ) > > Hope this helps. > > > > > > > >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Mezzanine Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Stephen McDonald > http://jupo.org > -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
