Re: Django error report not being sent through email

[Daniel Rus Morales]

Hi Xin,

Maybe the server from which you are running the project can’t send emails.
I would try to send an email using the send_mail function from the shell:

$ python manage.py shell
>>> from django.core.mail import send_mail
>>> send_mail(’the subject’, ’the message’, ‘f...@example.com’, 
>>> [’t...@you.com’,])

It shouldn’t take more than a couple of seconds. If the session hangs I would 
look at the email settings (EMAIL_HOST, EMAIL_PORT, EMAIL_HOST_USER, and 
EMAIL_HOST_PASSWORD), maybe a sysadmin could tell you which values you must use 
to reach the network outside of your local network. Also the EMAIL_BACKEND must 
be django.core.mail.backends.smtp.EmailBackend.

If the function returns 1, then you were able to contact the SMTP server and 
deliver the message successfully to the server. However a misconfiguration in 
the SMTP Server might stop the outgoing message from reaching the mail server 
of your email address.

Give it a try and let us know.

 

> On 19 Sep 2015, at 14:27, Xin Ji  wrote:
> 
> No, I haven't.
> How should I override? And Which file should I put the LOGGING settings in?
> 
> 在 2015年9月19日星期六 UTC+8下午7:49:56，Xin Ji写道：
> I'm using apache + django + mod_wsgi to serve my app.
> My apache version is 2.4.7 and my django version is 1.8.4
> 
> My django settings are:
>   DEBUG=False
> 
>   ADMINS = [
>   ('username','usern...@comp.nus.edu.sg 
> '),
>   ]
> 
>   MANAGERS = [
>   ('username','usern...@comp.nus.edu.sg 
> '),
>   ]
> 
>   MIDDLEWARE_CLASSES = (
>   ...
>   'django.middleware.common.BrokenLinkEmailsMiddleware',
>   )
> 
>   EMAIL_HOST = 'stmp.comp.nus.edu.sg '
>   EMAIL_PORT = 25
>   EMAIL_HOST_USER = 'username'
>   EMAIL_HOST_PASSWORD = 'password'
> 
> When I ran the server, I got this error on the website(This page uses the 
> django 500.html template.):
> Server Error (500)
> 
> There's been an error. It's been reported to the site administrators via 
> email and should be fixed shortly. Thanks for your patience.
> 
> 
> But I didn't receive any email about the error report.
> 
> What's wrong with my configurations?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-users@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-users 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/68c1b621-1cb5-4dfd-bd22-921134a0d128%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8539430C-0EAC-462D-9B97-98CA9EFEC6EA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Show a model on the admin list index page

[Daniel Rus Morales]

I think it’s clear to me what you are trying to do. By overriding those methods 
in BarAdmin you go down that line (bypass the django admin permission system), 
but to get the app listed in the admin index page you would have to actually 
rewrite the view function. This view function makes an explicit verification on 
the add/change/delete permissions for the logged in user and app Foo, and as 
long as your users don’t have them granted for such app they can’t see it 
listed.

Going back to my concern on overriding the permissions system, have you 
considered getting the functionality by providing your staff users with 
permissions at app Foo configuration time? That way your users would get access 
and you would write less code. You would create a group and would assign 
permissions to the group. At AppConfig.ready() you could assign your users to 
the new group, and thus grant them access.

Best,
Daniel


On 07 Oct 2014, at 11:25, Andrea <andrea.g...@gmail.com> wrote:

> Dear Daniel,
> 
> thank you for your answer.
> I think I was not clear enough in explaining my problem. I will try to 
> rephrase the problem, please tell me if from the first message this point was 
> clear or seemed different.
> 
> I do want that the user is able to add or change some objects. My goal is to 
> bypass the django admin permission system, and overriding "has_*_permission" 
> methods seemed the correct option.
> 
> The following example is correlated but a bit simpler. Let's suppose I grant 
> the access to all the users to the admin panel (is_staff=True for each user).
> 
> Now I want them to be able to add an instance of Bar model.
> 
> class BarAdmin(admin.ModelAdmin):
> def has_add_permission(self, request):
> return True
> def has_module_permission(self, request):
> return True
> In my opinion that should do the trick, in fact the link to add a new 
> instance is enabled, but it's not shown in the admin index page (and that's 
> my problem).
> What I do not want to do is to specifically assign the `foo.add_bar` 
> permission under the `permissions` section in the user profile for each user.
> 
> Thanks for your time spent in tackling this issue.
> 
> Andrea
> 
> 2014-10-07 11:01 GMT+02:00 Daniel Rus Morales <m...@danir.us>:
> Hi Andrea,
> 
> I answer below in between lines.
> 
> On 07 Oct 2014, at 08:53, Andrea <andrea.g...@gmail.com> wrote:
> 
>> Let's suppose I have a Foo app with a Bar model with a owner field. I want a 
>> user to be able to edit all the instances for which obj.owner == 
>> request.user.
>> 
>> The model appears correctly in the admin panel for superusers and for users 
>> for which I have explicitly assigned the permission change_bar or add_bar, 
>> as explained here:
>> 
>> Assuming you have an application with an app_label foo and a model named 
>> Bar, to test for basic permissions you should use:
>> 
>> add: user.has_perm('foo.add_bar')
>> change: user.has_perm('foo.change_bar')
>> delete: user.has_perm('foo.delete_bar')
>> How can I show the model Bar in the admin index list without explicitly 
>> assigning foo.change_bar or foo.add_bar to the user?
>> 
>> 
> 
> You can’t. The admin interface of Django assumes that when a user has access 
> to the administrative interface of an App-Model it’s not to act as a mere 
> passive consumer with read-only access but rather as an active admin over the 
> content (add, change, delete). An administrator who does only inspect or 
> supervise the content doesn’t fit in the sort of administrator that the 
> Django administration app allows. It’s like allowing an administrator who 
> actually does not administer. 
> 
>> So far I tried the following, expecting the Bar model to appear in the index 
>> list page, but it didn't work.
>> 
>> class BarAdmin(admin.ModelAdmin):
>> def get_queryset(self, request):
>> qs = super(BarAdmin, self).get_queryset(request)
>> if request.user.is_superuser:
>> return qs
>> return qs.filter(owner=request.user)
>> 
>> def has_add_permission(self, request):
>> return True
>> 
>> def has_change_permission(self, request, obj=None):
>> if obj is None:
>> return True
>> if obj.owner == request.user:
>> return True
>> return False
>> 
>> def has_delete_permission(self, request, obj=None):
>> if obj is None:
>> return True
>> if obj.owner == request.user:
>> return True
>> return False
>> 
>> def has_modul

Re: Show a model on the admin list index page

[Daniel Rus Morales]

Hi Andrea,

I answer below in between lines.

On 07 Oct 2014, at 08:53, Andrea  wrote:

> Let's suppose I have a Foo app with a Bar model with a owner field. I want a 
> user to be able to edit all the instances for which obj.owner == request.user.
> 
> The model appears correctly in the admin panel for superusers and for users 
> for which I have explicitly assigned the permission change_bar or add_bar, as 
> explained here:
> 
> Assuming you have an application with an app_label foo and a model named Bar, 
> to test for basic permissions you should use:
> 
> add: user.has_perm('foo.add_bar')
> change: user.has_perm('foo.change_bar')
> delete: user.has_perm('foo.delete_bar')
> How can I show the model Bar in the admin index list without explicitly 
> assigning foo.change_bar or foo.add_bar to the user?
> 
> 

You can’t. The admin interface of Django assumes that when a user has access to 
the administrative interface of an App-Model it’s not to act as a mere passive 
consumer with read-only access but rather as an active admin over the content 
(add, change, delete). An administrator who does only inspect or supervise the 
content doesn’t fit in the sort of administrator that the Django administration 
app allows. It’s like allowing an administrator who actually does not 
administer. 

> So far I tried the following, expecting the Bar model to appear in the index 
> list page, but it didn't work.
> 
> class BarAdmin(admin.ModelAdmin):
> def get_queryset(self, request):
> qs = super(BarAdmin, self).get_queryset(request)
> if request.user.is_superuser:
> return qs
> return qs.filter(owner=request.user)
> 
> def has_add_permission(self, request):
> return True
> 
> def has_change_permission(self, request, obj=None):
> if obj is None:
> return True
> if obj.owner == request.user:
> return True
> return False
> 
> def has_delete_permission(self, request, obj=None):
> if obj is None:
> return True
> if obj.owner == request.user:
> return True
> return False
> 
> def has_module_permission(self, request):
> return True
> Accessing the link admin/foo/bar/ works correctly for every user and returns 
> the list of Bar instances for which obj.owner == request.user. 
> admin/foo/bar/add allows the user to add a new object correctly. These links 
> are although not displayed in the admin index page: which is the function 
> that triggers the appearance of the model in the index page? admin/foo/ 
> returns 403 Forbidden.
> 

Uhm… this looks strange to me. So you don’t want to provide the user with 
add/change/delete permissions but you are faking them. 

The Bar model doesn’t appear in the App index list page because the view 
function in charge first verifies whether the user has any of the 
add/change/delete permissions granted for such App, and given that your user 
doesn’t have them the App Foo is not listed. In other words, you would have to 
override the index admin view too (in django.contrib.admin.sites.py), which I 
don’t recommend. Think that by overriding the way permissions are handled in 
the admin interface you might end up giving change access to regular users that 
shouldn’t have access at all. 

My recommendation here is to create your own supervising interface for Foo, 
with its own URLs, to provide the readonly functionality your target users 
needs. Those users might not probably fall in the category of admins. I’m 
thinking in maybe managers who need to see what’s going on but doesn’t have to 
have write access.

Does this answer your questions?

> I'm using Django 1.7
> 
> Thanks,
> 
> Andrea
> 
> 

Cheers,
Daniel



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newbie Question: Django Tutorial Part 4 - Exception Issue

[Daniel Rus Morales]

My pleasure ;)
Enjoy coding!


On 01 Oct 2014, at 22:04, zaiks0105 <lah...@gmail.com> wrote:

> Daniel,
> 
> I appreciate your help. I got drifted away yesterday and got back to it 
> today. I found my mistake: a fricking typo. My polls/detail.html look for 
> 'error_message' while I spelt 'error_messge' in my views.py. So the error msg 
> was never shown though the page was redirected properly.
> 
> Thanks again!
> 
> On Monday, September 29, 2014 9:36:31 AM UTC-4, Daniel Rus Morales wrote:
> No, that’s not the cause, the lack of it would be. That line shows the 
> content of ‘error_message' when it does exist and has a value other than 
> None. But if you have it in your template the error must be somewhere else in 
> your code. Must be a simple syntax mistake you didn’t notice, either in the 
> template file or in the vote view.
> 
> To be sure that your code is raising an exception you can place a print 
> statement right after the except, before the call to render. Replace the call 
> to render with these lines, they do the same but also print a message in the 
> console:
> 
> except (KeyError, Choice.DoesNotExist):
> # redisplay the question voting form
> context = {
> 'question': p,
> 'error_message': "You didn't select a choice.",
> }
> print("context: ", context)
> return render(request, 'polls/detail.html', context)
> 
> 
> Click vote again and see what’s the output when you click on “Vote” without 
> selecting any choice. The text of the print statement will show up in the 
> console where you launched `python manage.py runserver`.
> 
> If you see the output “context: “ and the ‘error_message’ string with the 
> actual message, then you have a syntax mistake in your template. Otherwise 
> it’s in your view.
> 
> Cheers
> 
> 
> On 29 Sep 2014, at 14:55, zaiks0105 <lah...@gmail.com> wrote:
> 
>> I do. Is that line causing the behavior?
>> 
>> 
>> 
>> On Monday, September 29, 2014 7:15:47 AM UTC-4, Daniel Rus Morales wrote:
>> Hi Zaiks0105,
>> 
>> Do you have the following line in "your polls/templates/polls/detail.html”?
>> 
>> {% if error_message %}{{ error_message }}{% endif %}
>> 
>> On 29 Sep 2014, at 12:48, zaiks0105 <lah...@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> I am following Django official tutorial and have unanswered issue at part 
>>> 4, https://docs.djangoproject.com/en/1.7/intro/tutorial04/. Here is the 
>>> exception handling code,
>>> 
>>> except (KeyError, Choice.DoesNotExist):
>>> # Redisplay the question voting form.
>>> return render(request, 'polls/detail.html', {
>>> 'question': p,
>>> 'error_message': "You didn't select a choice.",
>>> })
>>> 
>>> When I run the server and click on [Vote] without selecting a choice, the 
>>> page does NOT show me the error message. The same voting page comes back as 
>>> if [Vote] was not clicked.
>>> I checked my lines and everything seems identical per tutorial.
>>> 
>>> Any help appreciated!
>>> Thanks
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/69aaa1bb-5371-4aec-ae1f-fb44880e46b3%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/2adefa94-7801-48ad-af1f-1d5ec10ada86%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/64a09fab-f34d-4847-9643-07290910f7c6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Config: DB or git?

[Daniel Rus Morales]

On 29 Sep 2014, at 17:13, Javier Guerra Giraldez  wrote:

> On Mon, Sep 29, 2014 at 8:15 AM, Alejandro Varas G.
>  wrote:
>>> But where does configuration belong?
>> 
>> "To the environment"
> 
> 
> this is the currently fashionable answer, but I haven't seen any
> justification for it.  Unfortunately, the 12factors manifesto tells
> the how, but very little of the why.
> 
> In my experience, environment variables are clumsy, fragile and a pain
> to work with.
> 
> I guess a more balanced option would be to store somewhere else,
> probably the database (although i'm not too opposed to VCS) with the
> host-variable parts (or everything, who cares about a couple KB extra
> storage?) as a set indexed by hostname, which is read from the
> environment.


I see configurable settings, like those in the settings module, as code 
settings, and those you would put in the DB as user customizable settings. The 
former are meant to be changed by developers and sys admins, and the latter by 
website users. In my opinion settings module changes are mostly related to 
staging or performance rather than user oriented. Apart from there are a number 
of interesting Django apps in Djangopackages [1] that allow you to put your 
settings in the DB.

[1] -> https://www.djangopackages.com/grids/g/configuration/

Regards


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newbie Question: Django Tutorial Part 4 - Exception Issue

[Daniel Rus Morales]

No, that’s not the cause, the lack of it would be. That line shows the content 
of ‘error_message' when it does exist and has a value other than None. But if 
you have it in your template the error must be somewhere else in your code. 
Must be a simple syntax mistake you didn’t notice, either in the template file 
or in the vote view.

To be sure that your code is raising an exception you can place a print 
statement right after the except, before the call to render. Replace the call 
to render with these lines, they do the same but also print a message in the 
console:

except (KeyError, Choice.DoesNotExist):
# redisplay the question voting form
context = {
'question': p,
'error_message': "You didn't select a choice.",
}
print("context: ", context)
return render(request, 'polls/detail.html', context)


Click vote again and see what’s the output when you click on “Vote” without 
selecting any choice. The text of the print statement will show up in the 
console where you launched `python manage.py runserver`.

If you see the output “context: “ and the ‘error_message’ string with the 
actual message, then you have a syntax mistake in your template. Otherwise it’s 
in your view.

Cheers


On 29 Sep 2014, at 14:55, zaiks0105 <lah...@gmail.com> wrote:

> I do. Is that line causing the behavior?
> 
> 
> 
> On Monday, September 29, 2014 7:15:47 AM UTC-4, Daniel Rus Morales wrote:
> Hi Zaiks0105,
> 
> Do you have the following line in "your polls/templates/polls/detail.html”?
> 
> {% if error_message %}{{ error_message }}{% endif %}
> 
> On 29 Sep 2014, at 12:48, zaiks0105 <lah...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I am following Django official tutorial and have unanswered issue at part 4, 
>> https://docs.djangoproject.com/en/1.7/intro/tutorial04/. Here is the 
>> exception handling code,
>> 
>> except (KeyError, Choice.DoesNotExist):
>> # Redisplay the question voting form.
>> return render(request, 'polls/detail.html', {
>> 'question': p,
>> 'error_message': "You didn't select a choice.",
>> })
>> 
>> When I run the server and click on [Vote] without selecting a choice, the 
>> page does NOT show me the error message. The same voting page comes back as 
>> if [Vote] was not clicked.
>> I checked my lines and everything seems identical per tutorial.
>> 
>> Any help appreciated!
>> Thanks
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/69aaa1bb-5371-4aec-ae1f-fb44880e46b3%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/2adefa94-7801-48ad-af1f-1d5ec10ada86%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newbie Question: Django Tutorial Part 4 - Exception Issue

[Daniel Rus Morales]

Hi Zaiks0105,

Do you have the following line in "your polls/templates/polls/detail.html”?

{% if error_message %}{{ error_message }}{% endif %}

On 29 Sep 2014, at 12:48, zaiks0105  wrote:

> Hi,
> 
> I am following Django official tutorial and have unanswered issue at part 4, 
> https://docs.djangoproject.com/en/1.7/intro/tutorial04/. Here is the 
> exception handling code,
> 
> except (KeyError, Choice.DoesNotExist):
> # Redisplay the question voting form.
> return render(request, 'polls/detail.html', {
> 'question': p,
> 'error_message': "You didn't select a choice.",
> })
> 
> When I run the server and click on [Vote] without selecting a choice, the 
> page does NOT show me the error message. The same voting page comes back as 
> if [Vote] was not clicked.
> I checked my lines and everything seems identical per tutorial.
> 
> Any help appreciated!
> Thanks
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/69aaa1bb-5371-4aec-ae1f-fb44880e46b3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Unable to delete cookie

[Daniel Rus Morales]

Did you try to remove the last subdomain and call again delete_cookie? Just 
curious.

On 26 Sep 2014, at 19:56, Tao Bojlen  wrote:

> I fixed this by using set_cookie() with a manually entered expiry date, 
> rather than delete_cookie(). Additionally, if I set the domain in Django, it 
> prefixed a period which meant that it didn't match the existing cookie. I 
> didn't enter a domain and it used the default, which worked.
> 
> 
> 
> On Tuesday, September 23, 2014 6:09:57 PM UTC+1, Tao Bojlen wrote:
> Hi,
> 
> I'm using a custom authentication backend for my Django project, and in order 
> to log out I have to delete a cookie that's set by the (external) 
> authentication site.
> Here is my view code:
> 
> response = django_logout(request,
>  next_page=post_logout_url)
> response.delete_cookie('cookie_name',
> domain="cookie_domain")
> return response
> 
> The Set-Cookie header of the view is fine:
> cookie_name=; Domain=cookie_domain; expires=Thu, 01-Jan-1970 00:00:00 GMT; 
> Max-Age=0; Path=/
> 
> But the cookie isn't changed at all - it has the same value and expiry date 
> ("end of session") as before logging out.
> 
> Does anyone have any ideas about why this is happening?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/b0c48f1c-4757-4298-a0b0-ec960f185662%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Unable to delete cookie

[Daniel Rus Morales]

Your code looks good. It seems to me you might have some middleware in your 
project, from the external authentication, that places the cookie. Think that 
the response in your view still have to pass through the middleware in its way 
out to the browser.

Just guessing.

On 24 Sep 2014, at 16:40, Tao Bror Bojlén  wrote:

> Everything's https, and it's the same path.
> Here's the cookie before going to the logout view, and the cookie header
> of that view: http://imgur.com/a/idlVT
> 
> As far as I can tell, they match, but the cookie isn't changed at all.
> 
> 
> On 24/09/2014 15:33, Collin Anderson wrote:
>> Could it be different paths or something? Or http vs https?
>> -- 
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-users/Glpa_myOGSw/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-users+unsubscr...@googlegroups.com
>> .
>> To post to this group, send email to django-users@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/7c23a976-8000-4ce7-a488-42cc0bee8510%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/5422D7CD.1040803%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Unable to delete cookie

[Daniel Rus Morales]

It sounds like you have a same-origin policy issue. If the external 
authentication site and your site have different origins you can’t delete their 
cookies with your responses. Does not the external authentication site provide 
you with a method to logout?

On 23 Sep 2014, at 19:09, Tao Bojlen  wrote:

> Hi,
> 
> I'm using a custom authentication backend for my Django project, and in order 
> to log out I have to delete a cookie that's set by the (external) 
> authentication site.
> Here is my view code:
> 
> response = django_logout(request,
>  next_page=post_logout_url)
> response.delete_cookie('cookie_name',
> domain="cookie_domain")
> return response
> 
> The Set-Cookie header of the view is fine:
> cookie_name=; Domain=cookie_domain; expires=Thu, 01-Jan-1970 00:00:00 GMT; 
> Max-Age=0; Path=/
> 
> But the cookie isn't changed at all - it has the same value and expiry date 
> ("end of session") as before logging out.
> 
> Does anyone have any ideas about why this is happening?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/1c643254-9800-4978-a236-a67d40cb973d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Django url pass through

[Daniel Rus Morales]

Hi Robert,

In those cases a HTTP 404 is the right response, to help Search Engines realise 
that such a URL doesn’t exist and to show users a "Page Not Found" message. To 
create a nice looking 404 response for users just write a view to handle it and 
add the “handler404” entry to your root URLConf module (the one near the 
settings.py module).

Adding something like this to urls.py:

handler404 = ‘views.http404_handler’

And creating that view in the corresponding views.py module:

from django.http import HttpResponseNotFound
from django.template import loader, RequestContext

def http404_handler(request):
t = loader.get_template("404.html")
return HttpResponseNotFound(
t.render(RequestContext(request, {'request_path': request.path})))

Also create the template 404.html in your templates directory.

Read more on the topic here: 
https://docs.djangoproject.com/en/1.7/ref/views/#the-404-page-not-found-view

Good luck,
Daniel


On 23 Sep 2014, at 04:25, robert brook  wrote:

> How is a url conf written so that if none of the useful urls are matched it 
> will pass through to some sort of wild card regular expressions so that the 
> view / redirection can be performed gracefully
> 
> Thanks
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/f981954c-679a-4000-9e4c-11d3e6ee3e09%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Testting field.label_tag

[Daniel Rus Morales]

Use the attribute ‘label’ rather than ‘label_tal’. The latter is the HTML 
element.

Do:

{% if field.label != 'Tags' %}
{{ field.label_tag }}
{% endif %}

Cheers

On 22 Sep 2014, at 10:51, Salvatore DI DIO  wrote:

> Hello,
> 
> I woulk like to test field.label_tag in the  fieldset.html template
> 
> For example I want to do:
> 
> {% if field.label_tag != 'Tags' %}
> {{ field.label_tag }}
> {% endif %}
> 
> But that seems to not work
>  
> Thanks for your suggestions
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/f49e012b-34f7-4ca6-adf4-9663a9a626af%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail