leandigo / django-oneall Goto Github PK

Add standard Django Internationalization.

When ONEALL['store_user_info'] == False users shuold be allowed to log in and no personally identifiable information (as provided by social networks) should be stored or made available at all.

This is a milestone issue to investigate whether there is full Django 2.x compatibility and add any related changes that didn't get their own issue.

TemplateSyntaxError: 'oneall' is not a valid tag library: ImportError raised loading django_oneall.templatetags.oneall: cannot import name get_user_model

django==1.8.11
django_oneall==1.2
pyoneall==0.2.3

I'm set this up per the samples from the django_oneall and pyoneall configuration docs and am getting this error on the django_oneall login.html template. Seems to be similar to #15 but in django_oneall 1.2

I was just working on changes to get this to work on django > 1.6 as well as python3, and noticed that the development branch has made such changes already. Your changes look better than mine, as I'm neither as familiar with django, oneall, or python3, so I'd much rather use yours (all I know is that my changes make it possible to python manage.py migrate without errors popping up anymore). Any ETA on when this will be ready?

This project integrates pretty tightly with default Django login infrastructure, which means there's a number of settings that must be present in the settings file. Things to check:

1. Do we have any of the appropriate AUTHENTICATION_BACKENDS?
2. If e-mail login is enabled, do we have both authentication and e-mail backends set?

See existing code in app.py for guidance.

This is a great first pull request if you want to join this project. I have no plans of implementing this myself.

This is the Python 3 provided by some distros such as Raspbian and Ubuntu LTS 12.

https://www.oneall.com/services/social-sharing/

Related to issue #1. Make sure generated usernames are under DB length limit. Detect that length if simple and reliable enough.

Django 1.10 up'd the length of auth_User.username from 30 to 150 chars.

This is fine for new users and/or new installations, but it causes existing users prior to an upgrade to be mis-identified.

I could put together a PR to fix this - just wanted some feedback first

I was thinking of simply adding another config option (only relevant for the pseudorandom usernames), such as 'pre_django1_10_usernames' (default=False) , and it's set to True simply use 30 chars instead of getting the username field length from the User models meta data.

The logic seems really simple, I imagine the main part is agreeing on the option name for the config.

-Scott

The README.rst file is getting a bit unwieldy and it's still pretty incomplete. Split it into Sphinx compatible documentation using the docs folder.

NVM, it took me 5 hours, but I discovered that I had my ONEALL_PUBLIC_KEY and ONEALL_PRIVATE_KEY reversed.

EDIT:
python 2.7.6
Django 1.8.12
django-oneall 1.1.2

I believe the culprit is an import error:

django_oneall/templatetags/oneall.py

from ..models import User, SocialUserCache 

and User is not defined in models.py

I remedied this by adding:

from django.contrib.auth import get_user_model

and then adding the call to get_user_model() in oneall_social_login() as so:

@register.inclusion_tag('oneall/social_login.html')
def oneall_social_login(user=None, **kwargs):
    """
    This tag displays the Social Login or Social Link widget.

    Don't forget to include ``{% oneall_header %}``!

    :param user: Logged in user for Social Link mode; if not provided, it's Social Login mode.
    :param kwargs: Widget options as documented by OneAll. For example, ``grid_sizes=[8,5]``
    """
    User = get_user_model()
    if isinstance(user, User):

Right now login.html and profile.html look like they're from 1990. Give it all a very basic easy-to-modify style so it can be used.

EDIT:
python 2.7.6
Django 1.8.12
django-oneall 1.1.2

Using django-oneall for admin login logs the user in just fine, but for some reason the user doesn't have any of their privileges. I'm merely assigning privs to Groups, and assigning Users to Groups, I haven't tried setting privs for individual users, to know if it's only the group privs, or all privs that are missing.

Of course everything works fine if I setsuperuser my user, but you shouldn't need to be a superuser to user the admin, merely staff and have privs to do things. Anyway, I can't be using setsuperuser to get admin access as different staff users have different privs, and I don't want them to automatically have all privs.

I haven't dug into Django's source code, but I'm wondering if the privs are cached along with the User in the session or something, rather than looking them up at each request. Perhaps, they need to be associated to the User object prior to returning it from an authentication function? Just a wild guess...