Re: logging in a user to more than one site
On 3/03/2011 15:15, Benedict Verheyen wrote:
> Hi,
>
> i have a problem with logging in a user to more than one site.
> SIte A and B are on the same subdomain.
>
> When a user visits site B, he is redirected to site A.
> Site A shows a login screen, checks the credentials with LDAP.
> After a succesful login, the user is redirected back to site B.
>
> However, when I then visit site A, the user is logged out (Anonymous)
> The userdatabase is in the database of site A and site B gets the info
> by using multiple databases and thus getting the info from site A.
>
> As for some more detailed info, site B has a login view.
> From there, I redirect to site A with a return param specified as GET
> parameter to
> this same login view.
> When i get there, i receive the user id, and get the user like this (in the
> backend to authenticate)
>
> user = User.objects.using('central_users').get(pk=key)
>
> where 'central_users' is specified in settings.py:
>
> 'central_users': {
> 'ENGINE': 'django.db.backends.postgresql_psycopg2',
> 'NAME': 'site A',
> 'USER': 'xxx',
> 'PASSWORD': 'xxx',
> 'HOST': 'localhost',
> 'PORT': '',
> }
>
> This finally works but as i said, I then run into problems on site A, the
> user is logged out.
> The user is first logged in, in site A when i check the credentials.
>
> Would this have anything to do with the fact that the user gets logged out
> later?
>
> Trying to log in a user to more than 1 site is more frustrating than i
> thought :)
>
> Regards,
> Benedict
>
Wow, what a pain this is.
I succeeded in making it work but I have to do some more testing to be sure my
solution is ok.
I had to make a User for site B as well and then, the user is logged in, in
site A and B.
Off course, having the same user object in Site B defeats the whole purpose.
I'm not sure I'm happy with the fact that you have to call authenticate before
a call to login.
In the login view of site B, i get the id of the user that is logged in.
So i thought this would work:
user = User.objects.using('central_users').get(pk=key)
login(request, user)
where 'central_users' is set in settings.py to link to the users database of
site A.
Off course, the above doesn't work because of the authenticate so you have to
write a backend.
No probs, you write the backend to get the users from 'central_users' and
return that user.
Simple enough.
Nope, if you do that, the user is logged out of site A.
I have only been able to solve this by creating a new user for site B.
As I said, i'm going to test further but it has been a painful journey.
Cheers,
Benedict
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
parameter, but not in the URL
Hi, Currently i pass all my parameterst hat a views needs over the URL. Eg. 127.0.0.1:800/93/1 This would delete an object with the id 93. This is very unsecure and once the user notices how this works he could delete any object he wants. How can i make this more secure ?! Kind regards . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Szabo XSLT Developer LexisNexis Marxergasse 25, 1030 Wien mailto:patrick.sz...@lexisnexis.at Tel.: +43 (1) 534 52 - 1573 Fax: +43 (1) 534 52 - 146 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Django 1.3 release candidate available
Hi, all of my 211 unittests pass, no single failure. Thank you for this high quality framework. Thomas Güttler On 04.03.2011 07:00, James Bennett wrote: > Tonight we're proud to announce the first release candidate for Django > 1.3; if all goes well, the final release will happen in about a week. > > Details for the release candidate are available on the official Django weblog: > > http://www.djangoproject.com/weblog/2011/mar/03/13-rc/ > > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: parameter, but not in the URL
On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: > 127.0.0.1:800/93/1 > > > > This would delete an object with the id 93. > > This is very unsecure and once the user notices how this works he > could delete any object he wants. > > > > How can i make this more secure ?! There's pretty much always a public-facing URL that can be used to delete a resource. I believe the best thing is just to require that a user be logged in to perform the action. That's most simply done with a @login_required decorator on the If you keep track of which users created which resources, you can restrict them to only deleting resources they created with some simple logic in the view. HTH, Eric -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
AW: parameter, but not in the URL
Hi, Thanks for you fast response ! I've already made sure that users can only edit or delete objects that they've created but i thought it might be even better to hide those information. Kind regards . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Szabo XSLT Developer LexisNexis Marxergasse 25, 1030 Wien mailto:patrick.sz...@lexisnexis.at Tel.: +43 (1) 534 52 - 1573 Fax: +43 (1) 534 52 - 146 -Ursprüngliche Nachricht- Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im Auftrag von Eric Abrahamsen Gesendet: Freitag, 04. März 2011 10:46 An: django-users@googlegroups.com Betreff: Re: parameter, but not in the URL On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: > 127.0.0.1:800/93/1 > > > > This would delete an object with the id 93. > > This is very unsecure and once the user notices how this works he > could delete any object he wants. > > > > How can i make this more secure ?! There's pretty much always a public-facing URL that can be used to delete a resource. I believe the best thing is just to require that a user be logged in to perform the action. That's most simply done with a @login_required decorator on the If you keep track of which users created which resources, you can restrict them to only deleting resources they created with some simple logic in the view. HTH, Eric -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Override default django Registration email
On 3 Mar, 14:23, bruno desthuilliers wrote: > On 3 mar, 13:39, Kenneth Gonsalves wrote: > > > On Thu, 2011-03-03 at 00:36 -0800, pols wrote: > > > Anyone knows how to override djangos default registration email.I > > > need to alter it to sent as html email instead of text email.As i am a > > > bigner of django help me with complete information > > > copy the templates to a folder called registration in your project and > > modify it how you like > > If the OP is talking about django-registration, overriding the > templates will not be enough, as > RegistrationProfile.send_activation_email sends plain text mails. Exactly, one need to hack django-registration email sending code (which is not difficult by the way: http://docs.djangoproject.com/en/1.2/topics/email/#sending-alternative-content-types). -- Tomasz Zielinski pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.2.5 postgres autocommit and contenttype sites tests failures
On 2 Mar, 00:10, Jason Culverhouse wrote: > Hi, > It seems that the contenttype framework and the sites contribs > conflict with using the autocommit:True database option. Do you really need that autocommit? Django has its own concept of autocommit, which seems to just work most of the time. With database-level autocommit turned on, Django-level transaction handling is not going to do anything useful. -- Tomasz Zielinski pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Need help with this basic query (annotate vs aggregate)
On 4 Mar, 01:19, Steven Sacks wrote: > Here is my model: > > class PlaylistTag(models.Model): > playlist = models.ForeignKey(Playlist) > tag = models.CharField(max_length=128) > tag_count = models.PositiveIntegerField(default=1) > > The way this model works is simple. If you add a tag to a playlist, > and the tag doesn't exist, the tag_count is 1. If you add the same tag > again to that playlist, the tag_count is incremented. If you remove > that tag, it is decremented. If it reaches 0, I remove the row > entirely. > > A playlist can have multiple tags and a tag can belong to different > playlists. > > (...) > > Does this make sense? IMHO - no, that doesn't make sense :-) What you need fior the start - and in fact write about - is: playlists = ManyToManyField(Playlist) and no `tag_count` field, unless you want denormalize your schema - which you probably don't. To count tags for given playlist, you simply do: playlist.playlisttag_set.count() Last but not least, looking at your SQL query it might be that I don't quite get what you need. -- Tomasz Zielinski pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Where does admin.py go?
Where does "admin.py" actually go? Do you need one for each of your applications or just one in the root of the project. Or does it go in an "admin" directory in your project? (Sorry, for the stupid question. I'm returning to an old project and restructuring it. In the process I have, as you imagine, knackered it up. I originally only used one 'core' application and had it in there. But now I want to split up the applications into different directories.) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: AW: parameter, but not in the URL
On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: > Hi, > > Thanks for you fast response ! > > I've already made sure that users can only edit or delete objects that > they've created but i thought it might be even better to hide those > information. If you put the delete link in a form "action", and have the delete view redirect to a different url when it's done, that's about as "hidden" as it gets. A determined user will still be able to figure out the pattern, but if they can only delete their own resoures, then why hide it? > > Kind regards > > > . . . . . . . . . . . . . . . . . . . . . . . . . . > Patrick Szabo > XSLT Developer > LexisNexis > Marxergasse 25, 1030 Wien > > mailto:patrick.sz...@lexisnexis.at > Tel.: +43 (1) 534 52 - 1573 > Fax: +43 (1) 534 52 - 146 > > > -Ursprüngliche Nachricht- > > Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im > Auftrag von Eric Abrahamsen > Gesendet: Freitag, 04. März 2011 10:46 > An: django-users@googlegroups.com > Betreff: Re: parameter, but not in the URL > > On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: > >> 127.0.0.1:800/93/1 >> >> >> >> This would delete an object with the id 93. >> >> This is very unsecure and once the user notices how this works he >> could delete any object he wants. >> >> >> >> How can i make this more secure ?! > > There's pretty much always a public-facing URL that can be used to > delete a resource. I believe the best thing is just to require that a > user be logged in to perform the action. That's most simply done with a > @login_required decorator on the > > If you keep track of which users created which resources, you can > restrict them to only deleting resources they created with some simple > logic in the view. > > HTH, > Eric > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Where does admin.py go?
On Friday, March 4, 2011 10:34:27 AM UTC, ALJ wrote: > > Where does "admin.py" actually go? Do you need one for each of your > applications or just one in the root of the project. Or does it go in > an "admin" directory in your project? > > (Sorry, for the stupid question. I'm returning to an old project and > restructuring it. In the process I have, as you imagine, knackered it > up. I originally only used one 'core' application and had it in there. > But now I want to split up the applications into different > directories.) > > One for each application. >From >http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#modeladmin-objects: "The ModelAdmin class is the representation of a model in the admin interface. These are stored in a file named admin.py in your application." -- DR. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: AW: parameter, but not in the URL
On 04/03/11 4:08 PM, Eric Abrahamsen wrote: On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: Hi, Thanks for you fast response ! I've already made sure that users can only edit or delete objects that they've created but i thought it might be even better to hide those information. If you put the delete link in a form "action", and have the delete view redirect to a different url when it's done, that's about as "hidden" as it gets. A determined user will still be able to figure out the pattern, but if they can only delete their own resoures, then why hide it? Kind regards . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Szabo XSLT Developer LexisNexis Marxergasse 25, 1030 Wien mailto:patrick.sz...@lexisnexis.at Tel.: +43 (1) 534 52 - 1573 Fax: +43 (1) 534 52 - 146 -Ursprüngliche Nachricht- Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im Auftrag von Eric Abrahamsen Gesendet: Freitag, 04. März 2011 10:46 An: django-users@googlegroups.com Betreff: Re: parameter, but not in the URL On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: 127.0.0.1:800/93/1 This would delete an object with the id 93. This is very unsecure and once the user notices how this works he could delete any object he wants. How can i make this more secure ?! There's pretty much always a public-facing URL that can be used to delete a resource. I believe the best thing is just to require that a user be logged in to perform the action. That's most simply done with a @login_required decorator on the If you keep track of which users created which resources, you can restrict them to only deleting resources they created with some simple logic in the view. HTH, Eric -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. Why don't you make the objects to be referred by a key rather than ID? e.g class Something (...): eid = StringField(max_length=48) # additional field. Then while creating this object, you make this eid as: import random as r import hashlib eid = hashlib.sha1 ( str(r.random()) + "MY_COOL_SALT" ) then you form your URLs like: /33bac54baa...33b/delete This won't make it 100% secure, but will make it almost impossible to guess an ID. Tx -- Shamail Tayyab Blog: http://shamail.in/blog -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
AW: AW: parameter, but not in the URL
Thats a good idea ! Thx . . . . . . . . . . . . . . . . . . . . . . . . . . Patrick Szabo XSLT Developer LexisNexis Marxergasse 25, 1030 Wien mailto:patrick.sz...@lexisnexis.at Tel.: +43 (1) 534 52 - 1573 Fax: +43 (1) 534 52 - 146 -Ursprüngliche Nachricht- Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im Auftrag von Shamail Tayyab Gesendet: Freitag, 04. März 2011 11:59 An: django-users@googlegroups.com Betreff: Re: AW: parameter, but not in the URL On 04/03/11 4:08 PM, Eric Abrahamsen wrote: > On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: > >> Hi, >> >> Thanks for you fast response ! >> >> I've already made sure that users can only edit or delete objects that >> they've created but i thought it might be even better to hide those >> information. > If you put the delete link in a form "action", and have the delete view > redirect to a different url when it's done, that's about as "hidden" as > it gets. A determined user will still be able to figure out the pattern, > but if they can only delete their own resoures, then why hide it? > >> Kind regards >> >> >> . . . . . . . . . . . . . . . . . . . . . . . . . . >> Patrick Szabo >> XSLT Developer >> LexisNexis >> Marxergasse 25, 1030 Wien >> >> mailto:patrick.sz...@lexisnexis.at >> Tel.: +43 (1) 534 52 - 1573 >> Fax: +43 (1) 534 52 - 146 >> >> >> -Ursprüngliche Nachricht- >> >> Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im >> Auftrag von Eric Abrahamsen >> Gesendet: Freitag, 04. März 2011 10:46 >> An: django-users@googlegroups.com >> Betreff: Re: parameter, but not in the URL >> >> On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: >> >>> 127.0.0.1:800/93/1 >>> >>> >>> >>> This would delete an object with the id 93. >>> >>> This is very unsecure and once the user notices how this works he >>> could delete any object he wants. >>> >>> >>> >>> How can i make this more secure ?! >> There's pretty much always a public-facing URL that can be used to >> delete a resource. I believe the best thing is just to require that a >> user be logged in to perform the action. That's most simply done with a >> @login_required decorator on the >> >> If you keep track of which users created which resources, you can >> restrict them to only deleting resources they created with some simple >> logic in the view. >> >> HTH, >> Eric >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. Why don't you make the objects to be referred by a key rather than ID? e.g class Something (...): eid = StringField(max_length=48) # additional field. Then while creating this object, you make this eid as: import random as r import hashlib eid = hashlib.sha1 ( str(r.random()) + "MY_COOL_SALT" ) then you form your URLs like: /33bac54baa...33b/delete This won't make it 100% secure, but will make it almost impossible to guess an ID. Tx -- Shamail Tayyab Blog: http://shamail.in/blog -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: logging in a user to more than one site
On 4/03/2011 10:05, Benedict Verheyen wrote:
> Wow, what a pain this is.
> I succeeded in making it work but I have to do some more testing to be sure
> my solution is ok.
>
> I had to make a User for site B as well and then, the user is logged in, in
> site A and B.
> Off course, having the same user object in Site B defeats the whole purpose.
>
> I'm not sure I'm happy with the fact that you have to call authenticate
> before a call to login.
> In the login view of site B, i get the id of the user that is logged in.
> So i thought this would work:
> user = User.objects.using('central_users').get(pk=key)
> login(request, user)
>
> where 'central_users' is set in settings.py to link to the users database of
> site A.
> Off course, the above doesn't work because of the authenticate so you have to
> write a backend.
> No probs, you write the backend to get the users from 'central_users' and
> return that user.
> Simple enough.
> Nope, if you do that, the user is logged out of site A.
> I have only been able to solve this by creating a new user for site B.
>
> As I said, i'm going to test further but it has been a painful journey.
>
> Cheers,
> Benedict
>
I have to make a user object on site B to make the login work.
This is not what I was after.
Is it possible to get a user from site A, return that info to site B and login
that user on
another site?
In my tests, I haven't succeeded in doing so.
Any info is appreciated,
Benedict
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Where does admin.py go?
OK. Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
HTML size confusion.
Hi there,
In my ModelForm I have a fields like this:
argument= models.CharField (max_length=50, blank=True)
media = models.CharField (max_length=50, choices =
getChoices ('media'))
For the 'media' field, the max_length results in a HTML select such
as:
-
monkey.png
shu-eumura-lcd.mpg
The problem here is that the max_length attribute has been passed to
the size, which results in a very large select control. If
max_length specifies the database storage size, why is it also used as
the size attribute to ? (Or rather: what am I doing wrong
here?)
I'm using django 1.2.1.
Cheers!
Rob
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Configuring Django-Sentry to send error mails
am using django-sentry for logging errors. I also want to enable
throttled error mails to be sent to admins whenever an error occurs.
But I can not get it working.
a) Normal django error mailing is working. b) but on removing ADMINS
and adding SENTRY_ADMINS(like below) it stops working:
DEBUG = False
TEMPLATE_DEBUG = DEBUG
SENTRY_TESTING = True
ADMINS = ()
SENTRY_ADMINS = ('my.n...@domain.com',)
MANAGERS = ADMINS
MIDDLEWARE_CLASSES = (
'sentry.client.middleware.SentryResponseErrorIdMiddleware',
)
EMAIL_USE_TLS = True
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'n...@gmail.com'
EMAIL_HOST_PASSWORD = 'password'
EMAIL_PORT = 587
Though entries are correctly being made and shown in panel. I mark all
errors as resolved before testing(to satisfy throttle condition of
sentry) but it is still not working.
Can anyone point to what I am doing wrong here?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Server HTTP Client
Hi all, Take a look at Twisted... http://twistedmatrix.com/trac/wiki/TwistedProject Regards, Rogerio Luz On Thu, Mar 3, 2011 at 9:02 PM, Julian wrote: > Hmm, yeah I heard about that. I was hoping to get something in Python. So > I'm can stay with one technology and language. > > > > On Mar 3, 2011, at 3:47 PM, Marwan Al-Sabbagh wrote: > > > mechanize is a very powerful library that can help you do this stuff. the > project page is at http://wwwsearch.sourceforge.net/mechanize . I've used > it in my work place and it works quite well. > > > > cheers, > > Marwan > > > > On Thu, Mar 3, 2011 at 9:59 PM, Julian wrote: > > Hi, > > > > Is there anything on in Python or Django that can be used as a server > > side HTTP Client. Something like HTTP Unit and jsdom from NodeJS. > > > > I'm trying to log into some custom site and scrap the data from them. > > It would be a plus if the client also support javascript. > > > > Thanks. > > > > > > Julian > > > > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > > To post to this group, send email to django-users@googlegroups.com. > > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > > To post to this group, send email to django-users@googlegroups.com. > > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- []´s Rogério Luz -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Syncing with an MS Exchange server...
Hello everyone, Part of an application I'm developing at the moment is messaging and one of the features should be ability to access an MS Exchange user account (not through IMAP) and get his emails, contacts and calendars (the code is not hosted on same server as Exchange; not even on a Windows node). For some time I'm trying to find a way to achieve this but without success. Does anyone have at least an idea what should I be looking for? Has anyone written anything similar in Python? Any tip/suggestion appreciated. My final move would be to look for opensource plugins for Evolution, Thunderbird, etc for Exchange synchronization and see how they did it... Thanks all, -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
permission module for Django views
Hi,
I have just released an experimental django-pobject, an expressive and
concise permission module for django views at goo.gl/L6h7D. It is
inspired by Q object of django.db. It supports bitwise operators AND ,
OR , XOR and invert ' ~ ' for complex permission construction. For
example, you can do something like this:
# permissions.py
def is_father(request, family_id, member_id):
return request.user.is_father(family_id)
def is_mother(request, family_id, member_id):
return request.user.is_father(family_id)
def is_child(request, family_id):
return request.user.is_child(family_id)
def is_neighbor(request, family_id):
return request.user.is_neighbor(family_id)
# views.py
@permission_required('', (P(is_father) | P(is_mother) | P(is_child)) &
~(neighbor))
def announce(request, family_id):
# makes announcement and returns a response
It somewhat overlaps object permissions introduced in Django 1.2 and
many object permission apps out there, but I feel another alternative
is probably welcome as well. This is experimental because I am not
sure if it is even relevant, but I use it for my projects.
Comment and constructive criticism are welcome.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: newbie going through basic tutorial
On Wed, Mar 2, 2011 at 4:43 PM, Alex Hall wrote: > Well, looks like things are suddenly working. I started over, and > changed two things: I removed the path from the database file name and > I gave it an extension of .db. The file appeared in the same place as > before, so my path was right, but the .db extension seems to have made > something quite happy as things are now working quite nicely. > Traceback shows you are working on Windows -- were you specifying the path with single backslashes? If so, that's likely the problem. If one of the single backslashes was interpreted as an escape sequence (see the table under: http://docs.python.org/reference/lexical_analysis.html#string-literals) then your path specification was essentially corrupted by Python's interpretation of the string literal, and SQLite was passed a name for a DB that it could not open (too bad it doesn't include that name in its error message, since that would be a good aid in figuring out problems like this). When specifying paths in Python code on Windows, it's best to use forward slashes. They are interpreted correctly and avoid this problem with backslashes in string literals. (You can also double the backslashes or specify the string a raw with the r prefix, but in general I find it easier to just always use forward slashes for the path separator.) Karen -- http://tracey.org/kmt/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Looking for a developer
I'm representing an international company that needs a website developed fast. (15weeks). We have the RFP to send out (today - March 4th) and are looking for interested developers. No parties will be considered after today. Sorry. Tight turnaround. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Looking for a developer
Hi, my firm would love to have a look at it. If we get the RFP, you sure would get a feedback from us. Kind regards. Sent from my BlackBerry wireless device from MTN -Original Message- From: Colleen Sender: django-users@googlegroups.com Date: Fri, 4 Mar 2011 05:05:54 To: Django users Reply-To: django-users@googlegroups.com Subject: Looking for a developer I'm representing an international company that needs a website developed fast. (15weeks). We have the RFP to send out (today - March 4th) and are looking for interested developers. No parties will be considered after today. Sorry. Tight turnaround. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Where does admin.py go?
This should further confirm to you there is always a need to put as many comments as you can in your application and codes as a matter of principle. Kind regards. Sent from my BlackBerry wireless device from MTN -Original Message- From: ALJ Sender: django-users@googlegroups.com Date: Fri, 4 Mar 2011 03:16:38 To: Django users Reply-To: django-users@googlegroups.com Subject: Re: Where does admin.py go? OK. Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.2.5 postgres autocommit and contenttype sites tests failures
On 04/03/11 10:01, Tomasz Zieliński wrote: > On 2 Mar, 00:10, Jason Culverhouse wrote: >> Hi, >> It seems that the contenttype framework and the sites contribs >> conflict with using the autocommit:True database option. > > Do you really need that autocommit? Django has its own concept of > autocommit, > which seems to just work most of the time. > With database-level autocommit turned on, Django-level transaction > handling > is not going to do anything useful. > Uhm. That's inaccurate in the postgresql case, IIRC. With the psycopg2 backend autocommit option on, if you /actually start a transaction/ via django (n.b. _including_ implicitly via turning on the normal django TransactionMiddleware*), you still get transactional behaviour. It's the initial/"outer" state is autocommit, which is useful for a variety of reasons (the one that we've found most useful is "intuitive" (conforming to naive user expectations) behaviour at the ./manage.py shell) * The TransactionMiddleware calls enter_transaction_management [1][2], which will boost the isolation level to 1 (from 0) if autocommit is on for the psycopg2 backend. [3] (noting managed=True in [2]) . If autocommit is off, then the isolation level is 1 anyway. [4] See psycopg2 docs for isolation level notes [5]. (I think django sources could do with using the relevant psycopg2 constants for the levels and not 0/1, but that's minor) [1] http://code.djangoproject.com/browser/django/trunk/django/middleware/transaction.py#L10 [2] http://code.djangoproject.com/browser/django/trunk/django/db/transaction.py#L32 [3] http://code.djangoproject.com/browser/django/trunk/django/db/backends/postgresql_psycopg2/base.py#L172 [4] http://code.djangoproject.com/browser/django/trunk/django/db/backends/postgresql_psycopg2/base.py#L109 [5] http://initd.org/psycopg/docs/extensions.html#isolation-level-constants -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Looking for a developer
Hi there - I am a freelance developer and would be delighted to look at the RFP and give you a quote. If I can be of further assistance please email me at b...@gtmuk.plus.com if you prefer not to use this group fro conact. May I ask what business sector the is for? Regards, Bill Tudor (UK) On Mar 4, 1:05 pm, Colleen wrote: > I'm representing an international company that needs a website > developed fast. (15weeks). We have the RFP to send out (today - March > 4th) and are looking for interested developers. > > No parties will be considered after today. Sorry. Tight turnaround. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Configuring Django-Sentry to send error mails
On 4 Mar, 05:49, Ajay wrote:
> am using django-sentry for logging errors. I also want to enable
> throttled error mails to be sent to admins whenever an error occurs.
> But I can not get it working.
>
> a) Normal django error mailing is working. b) but on removing ADMINS
> and adding SENTRY_ADMINS(like below) it stops working:
>
> DEBUG = False
> TEMPLATE_DEBUG = DEBUG
>
> SENTRY_TESTING = True
>
> ADMINS = ()
> SENTRY_ADMINS = ('my.n...@domain.com',)
>
> MANAGERS = ADMINS
>
> MIDDLEWARE_CLASSES = (
> 'sentry.client.middleware.SentryResponseErrorIdMiddleware',
>
> )
>
> EMAIL_USE_TLS = True
> EMAIL_HOST = 'smtp.gmail.com'
> EMAIL_HOST_USER = 'n...@gmail.com'
> EMAIL_HOST_PASSWORD = 'password'
> EMAIL_PORT = 587
>
> Though entries are correctly being made and shown in panel. I mark all
> errors as resolved before testing(to satisfy throttle condition of
> sentry) but it is still not working.
>
> Can anyone point to what I am doing wrong here?
Everything looks ok on the first sight. Do you have sentry and
sentry.client
in your INSTALLED_APPS ? Does console SMTP backend print anything ?
One thing that once bit me was that ADMINS required tuples,
whereas SENTRY_ADMINS was just a plain string list.
But you seem to have this set correctly.
--
Tomasz Zielinski
pyconsultant.eu
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
How to know when an admin form is completly saved to DB?
Hi, I have an admin class with some arbitrary number of inline forms. I want to make some stuff when all the inlines are successfully saved. How can I do that? admin executes something else after save_model ?? Thanks!! -- Marc -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Looking for a developer
I represent a two man designer/coder team which may be interested. RFP available for review? Curious as to what the scope is. - Huy On Fri, Mar 4, 2011 at 8:05 AM, Colleen wrote: > I'm representing an international company that needs a website > developed fast. (15weeks). We have the RFP to send out (today - March > 4th) and are looking for interested developers. > > No parties will be considered after today. Sorry. Tight turnaround. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Using markdown within admin interface
On Wednesday, February 23, 2011 06:36:46 am Jonas Geiregat wrote: > Hello, > > I love markdown for writing content on websites. I use it almost all the > time when I'm working with django. > > The only issue I hate is that the default django admin interface gives you > a standard textfield. There's nothing wrong with that but when you're > pasting some code on let's say a blog you need to prepend each line of > code with 4 spaces (or a tab). You can imagine that if you have several > lines of code this is frustrating. > > So my question is, how do you come around this issue or are there any > decent editors that work well with markup ? > > Regards, > > Jonas. Err my earlier tinymce suggestion was worng, also not the editor I was thinking of. Markitup[1] is the one I was thinking of. Mike [1] http://markitup.jaysalvat.com/examples/markdown/ -- What did you bring that book I didn't want to be read to out of about Down Under up for? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: curious about model classes
On Thursday, March 3, 2011 5:33:56 PM UTC+2, bruno desthuilliers wrote:
>
> On 3 mar, 15:16, kost BebiX wrote:
> > Yes, that's more a Python problem, not specifically django.
> >
> > You would normally do:
> >
> > class User(models.Model):
> > def __init__(self):
> > name = ...
> >
> > but this looks not cool) That's why most of python libraries use
> "declarative" syntax to describe models:
> >
> > class User(models.Model):
> > name = ...
>
>
> It has nothing to do with "looking cool" or anything like that. Using
> models.fields as class attributes in models class statement's body
> allow for the ORM to know what db fields and relations your table has
> - not what instance attributes a model instance will have. Well, not
> directly at least - of course the Model base case makes sure your
> instance will have corresponding instance attributes (for db fields),
> but note that these instance attributes are just plain python
> attributes, NOT the models.fields you defined at the class level.
>
>
Maybe you misunderstand what I was talking about. Doing
class A():
b = SomeFieldType()
will require the "powerful python object model" (oh, I like that :-) to put
in A's instance instance-variable b after all that. You say:
> Using models.fields as class attributes in models class statement's
body allow for the ORM to know what db fields and relations your table has -
not what instance attributes a model instance will have."
Yes. But more natural way would be to do something like
class A():
schema = {
'b': {'type': 'SomeType'}
}
And that would describe class's A attribute schema that would be
class-instance attribute from beginning till end (if there's no more magic),
but that looks ugly and broken.
Where am I wrong?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Ordering of querysets
Hi, I have trouble getting a QuerySet to do what I want. I need to select the last 10 items of a certain model (ordered by timestamp; so the "most recent" 10 items), and when I iterate over them during template processing I want the earliest item (with the oldest timestamp) to come first. I've tried to achieve this using various combinations of slicing, reverse(), and ordering on 'timestamp' vs '-timestamp', but I can't get it to work. How can this be done? Regards, Sidney -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Ordering of querysets
On Fri, Mar 4, 2011 at 4:06 PM, reddish wrote:
> Hi,
>
> I have trouble getting a QuerySet to do what I want. I need to select
> the last 10 items of a certain model (ordered by timestamp; so the
> "most recent" 10 items), and when I iterate over them during template
> processing I want the earliest item (with the oldest timestamp) to
> come first.
>
> I've tried to achieve this using various combinations of slicing,
> reverse(), and ordering on 'timestamp' vs '-timestamp', but I can't
> get it to work.
>
> How can this be done?
>
> Regards, Sidney
>
Unless I'm being dense, you cannot represent this as a single SQL
query, so logically you cannot represent this as a QuerySet. Dropping
to a little python, it is trivial:
>>> q=UsageLogEntry.objects.all().order_by('-time')[:10]
>>> items = list(q)
>>> items.reverse()
>>> for l in items: print l.time
...
2011-03-02 14:18:16
2011-03-02 14:18:23
2011-03-02 14:50:15
2011-03-02 15:24:16
2011-03-02 15:24:16
2011-03-02 15:24:23
2011-03-03 11:23:42
2011-03-03 11:28:49
2011-03-03 11:28:52
2011-03-04 12:30:15
If you absolutely must have a queryset, you can fudge it with two queries:
>>> q=UsageLogEntry.objects.all().order_by('-time')[:10]
>>> q_ids = list(q.values_list('id', flat=True))
>>> items = UsageLogEntry.objects.filter(id__in=q_ids).order_by('time')
>>> for l in items: print l.time
...
2011-03-02 14:18:16
2011-03-02 14:18:23
2011-03-02 14:50:15
2011-03-02 15:24:16
2011-03-02 15:24:16
2011-03-02 15:24:23
2011-03-03 11:23:42
2011-03-03 11:28:49
2011-03-03 11:28:52
2011-03-04 12:30:15
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: newbie going through basic tutorial
On 3/4/11, Karen Tracey wrote: > On Wed, Mar 2, 2011 at 4:43 PM, Alex Hall wrote: > >> Well, looks like things are suddenly working. I started over, and >> changed two things: I removed the path from the database file name and >> I gave it an extension of .db. The file appeared in the same place as >> before, so my path was right, but the .db extension seems to have made >> something quite happy as things are now working quite nicely. >> > > Traceback shows you are working on Windows -- were you specifying the path > with single backslashes? If so, that's likely the problem. If one of the > single backslashes was interpreted as an escape sequence (see the table > under: > http://docs.python.org/reference/lexical_analysis.html#string-literals) then > your path specification was essentially corrupted by Python's interpretation > of the string literal, and SQLite was passed a name for a DB that it could > not open (too bad it doesn't include that name in its error message, since > that would be a good aid in figuring out problems like this). Yes, that would be helpful. I was using single forward slashes, though, and I did get a file created, it just then said it could not open it. For whatever reason, adding the .db extension seems to have done the trick. > > When specifying paths in Python code on Windows, it's best to use forward > slashes. They are interpreted correctly and avoid this problem with > backslashes in string literals. (You can also double the backslashes or > specify the string a raw with the r prefix, but in general I find it easier > to just always use forward slashes for the path separator.) I usually use raw strings. I never knew you could use forward slashes on Windows, since shell prompts always require backslashes. This is really good to know! > > Karen > -- > http://tracey.org/kmt/ > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Have a great day, Alex (msg sent from GMail website) mehg...@gmail.com; http://www.facebook.com/mehgcap -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: adding model_dict['admin'] = model_admin is good idea?
On Fri, Mar 4, 2011 at 1:51 AM, hdknr wrote: > Hello, > > I'm customizing admin UI to add extra menus but I found it is not > easy. So thinking of adding "admin" to model_dict in index() and > app_index() ( source:django/trunk/django/contrib/admin/sites.py ) to > refere to ModeAdmin objects in templates. > Is there any pitfall in the security point of view ? > The admin is a wonderful thing. It certainly provides more than adequate tools for many situations. It provides for certain easy customizations. But if you find yourself wanting to go far outside its design philosophy, perhaps you should be considering writing your own, separate, view. You can still do whatever permissions checking you need, display whatever forms, etc., that you want, and your code will not require changes to keep in step with an advancing admin API if you upgrade to some future version of Django. That's not to say that the admin API may not someday directly support the features you need, but if it doesn't now, then you must consider where to best invest your effort. Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: AW: parameter, but not in the URL
You might also pass the necessary parameters in a POST type form, where the parameters don't appear in the URL, and if you're really security conscious you can require that the POST come over https. Bill On Fri, Mar 4, 2011 at 6:00 AM, Szabo, Patrick (LNG-VIE) wrote: > Thats a good idea ! > > Thx > > > . . . . . . . . . . . . . . . . . . . . . . . . . . > Patrick Szabo > XSLT Developer > LexisNexis > Marxergasse 25, 1030 Wien > > mailto:patrick.sz...@lexisnexis.at > Tel.: +43 (1) 534 52 - 1573 > Fax: +43 (1) 534 52 - 146 > > > -Ursprüngliche Nachricht- > > Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] Im > Auftrag von Shamail Tayyab > Gesendet: Freitag, 04. März 2011 11:59 > An: django-users@googlegroups.com > Betreff: Re: AW: parameter, but not in the URL > > On 04/03/11 4:08 PM, Eric Abrahamsen wrote: >> On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: >> >>> Hi, >>> >>> Thanks for you fast response ! >>> >>> I've already made sure that users can only edit or delete objects that >>> they've created but i thought it might be even better to hide those >>> information. >> If you put the delete link in a form "action", and have the delete view >> redirect to a different url when it's done, that's about as "hidden" as >> it gets. A determined user will still be able to figure out the pattern, >> but if they can only delete their own resoures, then why hide it? >> >>> Kind regards >>> >>> >>> . . . . . . . . . . . . . . . . . . . . . . . . . . >>> Patrick Szabo >>> XSLT Developer >>> LexisNexis >>> Marxergasse 25, 1030 Wien >>> >>> mailto:patrick.sz...@lexisnexis.at >>> Tel.: +43 (1) 534 52 - 1573 >>> Fax: +43 (1) 534 52 - 146 >>> >>> >>> -Ursprüngliche Nachricht- >>> >>> Von: django-users@googlegroups.com [mailto:django-users@googlegroups.com] >>> Im Auftrag von Eric Abrahamsen >>> Gesendet: Freitag, 04. März 2011 10:46 >>> An: django-users@googlegroups.com >>> Betreff: Re: parameter, but not in the URL >>> >>> On Fri, Mar 04 2011, Szabo, Patrick (LNG-VIE) wrote: >>> 127.0.0.1:800/93/1 This would delete an object with the id 93. This is very unsecure and once the user notices how this works he could delete any object he wants. How can i make this more secure ?! >>> There's pretty much always a public-facing URL that can be used to >>> delete a resource. I believe the best thing is just to require that a >>> user be logged in to perform the action. That's most simply done with a >>> @login_required decorator on the >>> >>> If you keep track of which users created which resources, you can >>> restrict them to only deleting resources they created with some simple >>> logic in the view. >>> >>> HTH, >>> Eric >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django users" group. >>> To post to this group, send email to django-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-users?hl=en. > > Why don't you make the objects to be referred by a key rather than ID? > > e.g > > class Something (...): > eid = StringField(max_length=48) # additional field. > > Then while creating this object, you make this eid as: > import random as r > import hashlib > eid = hashlib.sha1 ( str(r.random()) + "MY_COOL_SALT" ) > > then you form your URLs like: > /33bac54baa...33b/delete > > This won't make it 100% secure, but will make it almost impossible to > guess an ID. > > Tx > > -- > Shamail Tayyab > Blog: http://shamail.in/blog > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Need a sample example code for posgresql oriented django project
I need a sample example code for posgresql oriented django project It will do only insert, update, delete. I installed postgresql on windows. What would be the user,password for postgresql in settings.py? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: adding model_dict['admin'] = model_admin is good idea?
Thanks Bill You're right. I'll try in the other way with using template tags. Because the only useful information is "admin_url" like '/myapp/ mymodel', the tag will find tempate like 'templates/admin/myapp/mymodel/ menu.html' and return render_to_string() of that. --- hideki On 3月5日, 午前2:07, Bill Freeman wrote: > On Fri, Mar 4, 2011 at 1:51 AM, hdknr wrote: > > Hello, > > > I'm customizing admin UI to add extra menus but I found it is not > > easy. So thinking of adding "admin" to model_dict in index() and > > app_index() ( source:django/trunk/django/contrib/admin/sites.py ) to > > refere to ModeAdmin objects in templates. > > Is there any pitfall in the security point of view ? > > The admin is a wonderful thing. It certainly provides more than > adequate tools for many situations. It provides for certain easy > customizations. But if you find yourself wanting to go far outside > its design philosophy, perhaps you should be considering writing > your own, separate, view. You can still do whatever permissions > checking you need, display whatever forms, etc., that you want, > and your code will not require changes to keep in step with an > advancing admin API if you upgrade to some future version of > Django. > > That's not to say that the admin API may not someday directly > support the features you need, but if it doesn't now, then you > must consider where to best invest your effort. > > Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Training at Hyderabd
Hi All, If anybody belongs to Hyderabad.Can you please provide me training on Dajngo framework.Or atleast guide me. Regards Vijay -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Unable to process my form
Hi Silvio,
Still i am getting TemplateDoesNotFound error.Please suggest me
Regards
Vijay
On Thu, Mar 3, 2011 at 6:41 PM, Silvio wrote:
> You don't want to pass an absolute path to render_to_response. You
> want to pass a relative path. Right now you're passing '/home/prvr/
> Desktop/djcode/mysite/books/search_form.html'. You want something
> along the lines of "books/search_form.html".
>
> Then in your settings.py file, be sure to add '/home/prvr/Desktop/
> djcode/mysite/' as one of the TEMPLATE_DIRS entries.
>
> Hope that helps,
>
> Silvio
>
> On Mar 3, 8:00 pm, Vijay wrote:
> > Hi All,
> > I am new to django.I am practicing Django using the book "The
> > Definitive Guide to Django" by Jacob and Adrian.I have installed
> > Django on Ubuntu.I tried to process HTML form as directed in that
> > book,then i am getting the following error.Please suggest me a
> > solution for this.
> >
> > Environmen:
> >
> > Request Method: GET
> > Request URL:http://127.0.0.1:8000/search-form/
> > Django Version: 1.2.4
> > Python Version: 2.6.4
> > Installed Applications:
> > ['django.contrib.auth',
> > 'django.contrib.contenttypes',
> > 'django.contrib.sessions',
> > 'django.contrib.sites',
> > 'django.contrib.messages',
> > 'mysite.books']
> > Installed Middleware:
> > ('django.middleware.common.CommonMiddleware',
> > 'django.contrib.sessions.middleware.SessionMiddleware',
> > 'django.middleware.csrf.CsrfViewMiddleware',
> > 'django.contrib.auth.middleware.AuthenticationMiddleware',
> > 'django.contrib.messages.middleware.MessageMiddleware')
> >
> > Template Loader Error:
> > Django tried loading these templates, in this order:
> > Using loader django.template.loaders.filesystem.Loader:
> > Using loader django.template.loaders.app_directories.Loader:
> >
> > Traceback:
> > File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/
> > base.py" in get_response
> > 100. response = callback(request,
> > *callback_args, **callback_kwargs)
> > File "/home/prvr/Desktop/djcode/mysite/../mysite/books/views.py" in
> > search_form
> > 4. return render_to_response('/home/prvr/Desktop/djcode/mysite/
> > books/search_form.html')
> > File "/usr/local/lib/python2.6/dist-packages/django/shortcuts/
> > __init__.py" in render_to_response
> > 20. return HttpResponse(loader.render_to_string(*args,
> > **kwargs), **httpresponse_kwargs)
> > File "/usr/local/lib/python2.6/dist-packages/django/template/
> > loader.py" in render_to_string
> > 181. t = get_template(template_name)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django 1.2.5 postgres autocommit and contenttype sites tests failures
On 4 Mar, 14:22, David De La Harpe Golden wrote: > On 04/03/11 10:01, Tomasz Zieliński wrote: > > > On 2 Mar, 00:10, Jason Culverhouse wrote: > >> Hi, > >> It seems that the contenttype framework and the sites contribs > >> conflict with using the autocommit:True database option. > > > Do you really need that autocommit? Django has its own concept of > > autocommit, > > which seems to just work most of the time. > > With database-level autocommit turned on, Django-level transaction > > handling > > is not going to do anything useful. > > Uhm. That's inaccurate in the postgresql case, IIRC. Ah, you are right! I assumed that it's implemented in a simlar way across all backends. MySQL backend doesn't mess with isolation levels and database autocommit, leaving default autocommit=False, as Python DB API requires. -- Tomasz Zielinski pyconsultant.eu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Ordering of querysets
Hi Tom, > Unless I'm being dense, you cannot represent this as a single SQL > query, so logically you cannot represent this as a QuerySet. It is possible by using a nested query, e.g. SELECT * FROM (SELECT * FROM some_table ORDER BY timestamp DESC LIMIT 10) ORDER BY timestamp ASC; But I suppose QuerySets are designed to map onto a single, non-nested query (I don't know the innards of Django I'm afraid) so such a construct would be out of reach. An alternative would be to augment querysets such that it would be possible to iterate over them in reverse order. > Dropping to a little python, it is trivial True, but I had hoped it would be possible without doing that. Thanks, Sidney -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Form/view for ManyToMany relationship
On Thu, Mar 3, 2011 at 11:50 AM, werefr0g wrote: Hello, Sorry if I misunderstand, but what is wrong about using a ModelForm on your Film bounded to the film instance? My bad... how did I missed the intermediary model involved in the ManyToMany relashionship. Sorry. When I tried that I kept running into this error: "Cannot set values on a ManyToManyField which specifies an intermediary model. Use foo.FilmRole's Manager instead. As you are using an intermediary model, you must insert multiple FilmRole, one for each actor to this film, but you don't want using a formset, do you?. Is the following going toward your goal? # forms.py class FilmActorsForm(forms.Form): actors = forms.ModelMultipleChoiceField(queryset=Actors..., required=...) # views.py def assign_actors(film_id): film = get_object_or_404(Film, id=film_id) if request.method == 'POST': form = FilmActorsForm(request.POST) if form.is_valid(): chosen_actors = form.cleaned_data['actors'] current_actors = film.actors.all() # handle deletion / creation of filmroles return HttpResponseRedirect(...) else: form = FilmActorForm() Regards, -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Ordering of querysets
On Fri, 4 Mar 2011 21:40:36 +0100, Sidney Cadot wrote: Hi Sidney, > It is possible by using a nested query, e.g. > > SELECT * FROM (SELECT * FROM some_table ORDER BY timestamp DESC LIMIT 10) > ORDER BY timestamp ASC; Nice, but it doesn't make sense. It makes everything harder to understand. Reversing the results is a pretty simple thing - but I'm not sure if an SQL engine understands this well enough to result in good performance. Don't try to use SQL for everything, you don't have to. Kind regards Michael -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Form/view for ManyToMany relationship
sorry, I failed to pass the request to the view's function,.. Le 04/03/2011 22:08, werefr0g a écrit : On Thu, Mar 3, 2011 at 11:50 AM, werefr0g wrote: Hello, Sorry if I misunderstand, but what is wrong about using a ModelForm on your Film bounded to the film instance? My bad... how did I missed the intermediary model involved in the ManyToMany relashionship. Sorry. When I tried that I kept running into this error: "Cannot set values on a ManyToManyField which specifies an intermediary model. Use foo.FilmRole's Manager instead. As you are using an intermediary model, you must insert multiple FilmRole, one for each actor to this film, but you don't want using a formset, do you?. Is the following going toward your goal? # forms.py class FilmActorsForm(forms.Form): actors = forms.ModelMultipleChoiceField(queryset=Actors..., required=...) # views.py def assign_actors(film_id): film = get_object_or_404(Film, id=film_id) if request.method == 'POST': form = FilmActorsForm(request.POST) if form.is_valid(): chosen_actors = form.cleaned_data['actors'] current_actors = film.actors.all() # handle deletion / creation of filmroles return HttpResponseRedirect(...) else: form = FilmActorForm() Regards, -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
current recommendations for using email as username
I've found any number of threads on using email as username in django, but none that are both current and conclusive. "Just do ", followed by "But that breaks [the forms, the templates, the auth site, the registration, the db schema]" etc., where is something like "use email in the User username column", "use a randomly generated username", "use a hash for username", "write your own auth backend", "use django-emailauth", etc. What is the current state of this? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: current recommendations for using email as username
What's wrong with writing your own auth backend? It's two piddly functions: http://dpaste.com/hold/473373/ Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: current recommendations for using email as username
On Fri, Mar 4, 2011 at 1:34 PM, Shawn Milochik wrote: > What's wrong with writing your own auth backend? It's two piddly functions: > > http://dpaste.com/hold/473373/ > I think this has already been answered, in the comments here: http://djangosnippets.org/snippets/74/ and in the "motivation" section, here: https://github.com/redvasily/django-emailauth -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Form/view for ManyToMany relationship
On Fri, Mar 4, 2011 at 1:08 PM, werefr0g wrote: > On Thu, Mar 3, 2011 at 11:50 AM, werefr0g wrote: > > Hello, > > Sorry if I misunderstand, but what is wrong about using a ModelForm on your > Film bounded to the film instance? > > My bad... how did I missed the intermediary model involved in the ManyToMany > relashionship. Sorry. > > When I tried that I kept running into this error: > "Cannot set values on a ManyToManyField which specifies an > intermediary model. Use foo.FilmRole's Manager instead. > > As you are using an intermediary model, you must insert multiple FilmRole, > one for each actor to this film, but you don't want using a formset, do > you?. > > Is the following going toward your goal? > > # forms.py > class FilmActorsForm(forms.Form): > actors = forms.ModelMultipleChoiceField(queryset=Actors..., > required=...) > > # views.py > def assign_actors(film_id): > film = get_object_or_404(Film, id=film_id) > if request.method == 'POST': > form = FilmActorsForm(request.POST) > if form.is_valid(): > chosen_actors = form.cleaned_data['actors'] > current_actors = film.actors.all() > # handle deletion / creation of filmroles > return HttpResponseRedirect(...) > else: > form = FilmActorForm() Thanks. This is pretty close to what I'm doing. However, I'd like to not have to write all the associated boiler-plate (i.e. I have to figure out if any film/actor relationships have been deleted since the last save and explicitly write code to remove those and so on). It seems that I would even have this problem if I added a simple "auto now" date/time field to my relationship class, which seems a bit restrictive. ModelForm already knows how to do all that (it can do so when the relationship class is implicitly created) so what I imagined was *somewhere* I could override a method and provide the defaults for the missing fields and then it would all just works magically.Does this make sense? Can anyone give me any pointers to how I might do this (I'm keen to learn the "right way" to do things). I'm happy to hack this myself and contribute something if someone could give me some pointers of where I should start or where something like this ought to live. Thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Weird behaviour in Django logging (Django 1.3 RC)
I'm getting a strange behaviour when setting up logging. Here's my
logging configuration:
LOGGING =
{
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'admin_configuration': {
'format': '%(asctime)s %(levelname)s %(category)s %
(sub_category)s %(type_id)s %(message)s',
'datefmt': LOG_DATE_FORMAT,
},
},
'handlers': {
'admin_console': {
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'admin_configuration'
},
'db': {
'level':'DEBUG',
'class':'apps.history.handlers.DatabaseHandler',
'formatter': 'admin_configuration'
},
},
'loggers': {
'db_logger': {
'handlers': [ 'admin_console', 'db' ],
'level': 'DEBUG',
'propagate': False,
},
}
}
I then created a Database log handler and the log record will be
created using signals (e.g. on model save/delete) because I'm trying
to keep track of model changes. As you can see from my config, the
logger has 2 handlers, 1 for DB and 1 for stdout (stream handler).
I use the logger this way:
logging.getLogger('db_logger').log(level, msg, extra=extras)
where extras are extra attributes I'm passing to the logger.
Now the weird thing is, when I change the order of 'handlers'
definition under 'db_logger' to ['db', 'admin_console'], the logger
raises this error:
LogRecord instance has no attribute 'asctime'
After checking the record instance, 'message' attribute is generated
either, but all of my extra attributes are there.
The same error happens if I remove 'admin_console' handler. The only
way I can get the logger to work is that the handler must be in the
original order: 'handlers': [ 'admin_console', 'db' ]
Any idea why this is happening??
THanks.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: current recommendations for using email as username
Hello Brian, On Mar 4, 1:29 pm, Brian Craft wrote: > I've found any number of threads on using email as username in django, > but none that are both current and conclusive. "Just do ", followed > by "But that breaks [the forms, the templates, the auth site, the > registration, the db schema]" etc., where is something like "use > email in the User username column", "use a randomly generated > username", "use a hash for username", "write your own auth backend", > "use django-emailauth", etc. > > What is the current state of this? Email addresses have been allowed since version 1.2 < http://docs.djangoproject.com/en/1.2/topics/auth/#api-reference >. Have you found place in 1.2.x where an email address doesn't work? Toodle-lo.. creecode -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: current recommendations for using email as username
> > Email addresses have been allowed since version 1.2 < > http://docs.djangoproject.com/en/1.2/topics/auth/#api-reference >. > Have you found place in 1.2.x where an email address doesn't work? > > Toodle-lo.. > creecode The problem here is that the username is still limited to 30 characters. So plenty of e-mail addresses won't work. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Unable to process my form
What does the error say now? Post the traceback.
On Mar 4, 2:14 pm, vijay wrote:
> Hi Silvio,
> Still i am getting TemplateDoesNotFound error.Please suggest me
>
> Regards
> Vijay
>
>
>
>
>
>
>
> On Thu, Mar 3, 2011 at 6:41 PM, Silvio wrote:
> > You don't want to pass an absolute path to render_to_response. You
> > want to pass a relative path. Right now you're passing '/home/prvr/
> > Desktop/djcode/mysite/books/search_form.html'. You want something
> > along the lines of "books/search_form.html".
>
> > Then in your settings.py file, be sure to add '/home/prvr/Desktop/
> > djcode/mysite/' as one of the TEMPLATE_DIRS entries.
>
> > Hope that helps,
>
> > Silvio
>
> > On Mar 3, 8:00 pm, Vijay wrote:
> > > Hi All,
> > > I am new to django.I am practicing Django using the book "The
> > > Definitive Guide to Django" by Jacob and Adrian.I have installed
> > > Django on Ubuntu.I tried to process HTML form as directed in that
> > > book,then i am getting the following error.Please suggest me a
> > > solution for this.
>
> > > Environmen:
>
> > > Request Method: GET
> > > Request URL:http://127.0.0.1:8000/search-form/
> > > Django Version: 1.2.4
> > > Python Version: 2.6.4
> > > Installed Applications:
> > > ['django.contrib.auth',
> > > 'django.contrib.contenttypes',
> > > 'django.contrib.sessions',
> > > 'django.contrib.sites',
> > > 'django.contrib.messages',
> > > 'mysite.books']
> > > Installed Middleware:
> > > ('django.middleware.common.CommonMiddleware',
> > > 'django.contrib.sessions.middleware.SessionMiddleware',
> > > 'django.middleware.csrf.CsrfViewMiddleware',
> > > 'django.contrib.auth.middleware.AuthenticationMiddleware',
> > > 'django.contrib.messages.middleware.MessageMiddleware')
>
> > > Template Loader Error:
> > > Django tried loading these templates, in this order:
> > > Using loader django.template.loaders.filesystem.Loader:
> > > Using loader django.template.loaders.app_directories.Loader:
>
> > > Traceback:
> > > File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/
> > > base.py" in get_response
> > > 100. response = callback(request,
> > > *callback_args, **callback_kwargs)
> > > File "/home/prvr/Desktop/djcode/mysite/../mysite/books/views.py" in
> > > search_form
> > > 4. return render_to_response('/home/prvr/Desktop/djcode/mysite/
> > > books/search_form.html')
> > > File "/usr/local/lib/python2.6/dist-packages/django/shortcuts/
> > > __init__.py" in render_to_response
> > > 20. return HttpResponse(loader.render_to_string(*args,
> > > **kwargs), **httpresponse_kwargs)
> > > File "/usr/local/lib/python2.6/dist-packages/django/template/
> > > loader.py" in render_to_string
> > > 181. t = get_template(template_name)
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Syncing with an MS Exchange server...
On 4 March 2011 23:23, illuminated wrote: > Hello everyone, > > Part of an application I'm developing at the moment is messaging and > one of the features should be ability to access an MS Exchange user > account (not through IMAP) and get his emails, contacts and calendars > (the code is not hosted on same server as Exchange; not even on a > Windows node). > > For some time I'm trying to find a way to achieve this but without > success. > > Does anyone have at least an idea what should I be looking for? Has > anyone written anything similar in Python? Any tip/suggestion > appreciated. If you can enforce a requirement for Exchange 2007 or later, the easiest way would be to use Exchange Web Services, which are based on SOAP messages. This I believe is how Apple implemented Exchange support in OSX. Reference - http://msdn.microsoft.com/en-us/library/bb204119.aspx Example from Unix shell - http://blogs.msdn.com/b/exchangedev/archive/2009/02/05/quick-and-dirty-unix-shell-scripting-with-ews.aspx If you're familiar with Java, Microsoft has released the source code to the Java version of their EWS client API here (http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5501). You could consider using that as inspiration for whatever functionality you need in Python. If you have to support Exchange 2003, then you'll have to use WebDAV to interact with Exchange. There are plenty of references for this one the web. It is considered a legacy API though, and at some point in the future, will probably be removed. > My final move would be to look for opensource plugins for Evolution, > Thunderbird, etc for Exchange synchronization and see how they did > it... > > Thanks all, > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
On Thu, Mar 3, 2011 at 8:24 AM, Karen Tracey wrote: > A real fix I believe would need to be made to the Python library code to > ensure that it doesn't die if the windows registry contains non-ASCII data. > In fact there is a bug open in the Python bug tracker for this: http://bugs.python.org/issue9291 Karen -- http://tracey.org/kmt/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: current recommendations for using email as username
It would be grand if the max_length was upped. On Mar 4, 7:51 pm, Shawn Milochik wrote: > > Email addresses have been allowed since version 1.2 < > >http://docs.djangoproject.com/en/1.2/topics/auth/#api-reference>. > > Have you found place in 1.2.x where an email address doesn't work? > > The problem here is that the username is still limited to 30 > characters. So plenty of e-mail addresses won't work. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Looking for a developer
On Fri, 2011-03-04 at 13:10 +, delegb...@dudupay.com wrote: > Hi, my firm would love to have a look at it. If we get the RFP, you > sure would get a feedback from us. could you keep such posts offlist please -- regards KG http://lawgon.livejournal.com Coimbatore LUG rox http://ilugcbe.techstud.org/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
