On Mon, Jan 30, 2017 at 3:42 AM, CJWalther <cjwalt...@gmail.com> 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 ). 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 mezzanine-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
