configurazione django-allauth dubita

Question

sto usando django-allauth con Django 1.5.1 e ho un paio di domande, quando la sua creazione:

1. Configurare urls.py

la documentazione dice che si deve aggiungere quanto segue al urls.py di file:

urlpatterns = patterns('', 
    ... 
    (r'^accounts/', include('allauth.urls')), 
    ... 
) 

il problema è che ho già un'applicazione personalizzata chiamato accounts e ho già uso il followin g modello URL:

(r'^accounts/', include('accounts.urls')), 

quindi ho una collisione denominazione qui con l'URL accounts/ regex. La mia domanda è: posso rinominare lo schema URL allauth su (r'^auth/', include('allauth.urls')) senza problemi, o è pericoloso farlo e sarebbe meglio rinominare il mio URL con qualcosa come (r'^users/', include('users.urls')) (e rinominare la mia app per account con gli utenti per denominare la coerenza).

2. modelli Personalizza allauth predefiniti

Qual è il modo corretto per personalizzare i modelli predefiniti per il login, ecc? Penso che modificare direttamente la libreria non sia l'approccio migliore. Immagino che dovrebbe essere fatto attraverso la directory templates usando una gerarchia di directory concreta. Inoltre, non so se è necessario fornire una specie di file base.html per estendersi da quando si sostituiscono questi modelli o il numero base.html del sito che tutte le pagine possono essere utilizzate senza problemi. Potresti illustrarmi questo?

3. Admin form di login mostra login ei logout la prima volta che accede

Quando accedo al pannello di amministrazione, dopo alcune login ei logout appare la storia, ma se mi aggiorna la pagina poi scompare. Penso che questo deve essere qualcosa legato con i messaggi Django:

4. Impostare SOCIALACCOUNT_PROVIDERS

è l'impostazione dizionario chiamato SOCIALACCOUNT_PROVIDERS opzionale o deve essere impostato?

5. Come viene calcolata la password quando un utente accede con un'app di terze parti?

Quando l'utente viene creato ha una password, ma come viene calcolata? E ... è utile o è solo un segnaposto per questo campo richiesto? L'utente può utilizzarlo per l'accesso locale?

Grazie!

Answer 1

Per quanto riguarda 1):

• Non v'è alcuna collisione fintanto che non v'è alcuna sovrapposizione dei modelli di URL pienamente abbinati. Ad esempio: se l'app per i tuoi account ha una corrispondenza per "/ account/login /", allora c'è effettivamente una collisione come allauth sta sparando anche per quell'URL.Ma, se la tua app per account corrisponde semplicemente ad altri URL con/accounts/come prefisso, allora stai bene.

• Se insisti, puoi effettivamente mettere gli URL di allauth sotto un percorso diverso. allauth utilizza l'inversione dell'URL basata sul nome, quindi il nuovo prefisso del percorso verrà prelevato automaticamente.

Quanto a 2):

• Non c'è niente di speciale allauth modelli. Puoi sostituirli come faresti per qualsiasi altra app di Django.

• Dai un'occhiata all'app di esempio. Dispone sia di Bootstrap che di sovrascrittura di modelli uniformi. Possono essere abilitati decommentando questa riga: https://github.com/pennersr/django-allauth/blob/901485557d4ddee30fed920f2159cdf499c39e1c/example/example/settings.py#L126

• Tutti i modelli allauth ereditano da un modello di base, denominato base.html. Mi aspetto che il tuo progetto abbia anche un modello base. O ignorare l'base.html con il vostro, o, ignorare base.html con un modello che si estende dal yourbase.html

3): allauth utilizza i messaggi framework Django. Vedi: https://docs.djangoproject.com/en/dev/ref/contrib/messages/#expiration-of-messages - se non si scorre i messaggi per visualizzarli, non scadono. Quindi a quanto pare non stai mostrando i messaggi nei tuoi modelli. Pertanto, essi si accumulano fino a quando appare l'amministratore che rende (e cancella) tutti i messaggi raccolti finora ...

4) opzionale

5) Non v'è alcuna password impostata, significato, l'utente può solo Entra utilizzando l'account di terze parti fino a quando non imposta effettivamente una password (/ account/password/set /).