Maintenance about django-wordpress-auth HOT 9 CLOSED

Hey, cool! I'm not really working on anything Django or Wordpress related at the moment (though I am wearing a Django hoodie), but I'd be happy to take a look at any PRs you have. And if you are very interested in working on it I'd be happy to add you as a maintainer (or whatever it's called on github).

from django-wordpress-auth.

About to push my changes! It's on mstrcnvs/django-wordpress-auth. It's not fully tested though, I'm testing right now.

from django-wordpress-auth.

Pushed, there's some refactoring involved, I hope you don't mind.

from django-wordpress-auth.

Looks good to me so far. Let me know when you have tested it fully and feel like it's good to go. I like most of the changes you've made, but I'm not sure about the renaming to simply wordpress_auth. Most of the patterns around Django applications I've seen have the prefix of django-, unless it's using a name that is specific enough to the project to not cause confusion.

A few popular examples:

• https://github.com/django-debug-toolbar/django-debug-toolbar
• https://bitbucket.org/ubernostrum/django-registration/overview
• https://github.com/ericflo/django-pagination

I like this because as a Python library, it distinguishes between a generic WordPress (appreciate the spelling correction :) ) authentication library and one that is intended to work with Django. I imagine there would also be benefits for search engines, since I imagine that's what led you here in the first place!

from django-wordpress-auth.

I didn't change the project name to wordpress_auth, its still django-wordpress-auth and will be it on PyPI also. It's just the main package name, as an example you already sent, despite being named django-debug-toolbar the main package is simply named debug_toolbar, also django-registration which have its main package named registration. This is because it's a little redundant to specify django_wordpress_auth.middleware.blabla inside your Django project, you're in Django already :)

What I'm struggling with right now is that it seems that the algorithm you used to check if the cookie corresponds to a valid WordPress user is a little outdated, I think, the cookie now has 4 values separated by | instead of three, I think I'll have to do some more refactoring regarding this. Do you have any info if the cookie creation algorithm change in the last year?

from django-wordpress-auth.

I see, that makes sense.

This is pulling from really old memories, but I believe they had implemented something new but still had compatibility for the old way of storing things when I wrote this. It looks like the code lives in this function: https://github.com/WordPress/WordPress/blob/e253251ef410667cc13d2e7afb91178f9c929c48/wp-includes/pluggable.php#L616

Hopefully that helps some.

from django-wordpress-auth.

I'm trying to come up with a solution while maintaining backwards compatibility. Like exposing an endpoint on the WordPress installation that checks itself for the validity of the cookie. But that would require a WordPress plugin.

from django-wordpress-auth.

If you've managed to get a working version of the new one, could you just
check for the validity of either and pass if okay? That being said, anyone
who is still on that old of a WordPress release probably should be
upgrading for security's sake.

On Wed, Jan 7, 2015 at 7:53 AM, Rafael Canovas [email protected]
wrote:

I'm trying to struggle with a solution while maintaining backwards
compatibility. Like exposing an endpoint on the WordPress installation that
checks itself for the validity of the cookie. But that would require a
WordPress plugin.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

from django-wordpress-auth.

Yeah you're right. Let's do it then :-)

from django-wordpress-auth.