Django webapp kan zijn sessie niet herstellen op de iPad

[VTe]

Ik ben op dit moment in Django een webapp aan het ontwikkelen die vanaf het homescreen op de iPad moet worden gestart. Iedere gebruiker moet op zijn/haar iPad inloggen en de sessie moet een X aantal maanden geldig blijven. Het sluiten van de webapp en het herstarten van de iPad mogen geen invloed hebben op de sessie-duur. Ik heb dit eerder gedaan in PHP en die projecten werken sinds iOS8 prima.

Helaas werkt het bovengenoemde alleen goed op de desktop en de mobiele Safari. Het openen van de webapp via het homescreen laat het loginscherm zien, die ik vervolgens invoer. Als ik via de Safari debugger op de Mac kijk naar de cookie op de iPad, zie ik dat de cookie (op dit moment) tot 2017 geldig is. Daarmee concludeer ik dat de cookie-instellingen correct werken:

Python:

SESSION_SAVE_EVERY_REQUEST = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_AGE = 31556928  # one year

Als ik de sessie-data voor de session ID in de cookie opzoek, zie ik goede waardes voor

_auth_user_id

en

_auth_user_hash

. Deze waardes, evenals de session ID, veranderen ook niet wanneer ik de webapp geforceerd afsluit en voor een tweede, derde of vierde keer inlog.

Het project heeft een eigen virtualenv, waarin de volgende packages geinstalleerd zijn:

Django (1.8.7)
django-appconf (1.0.1)
django-ckeditor (5.0.2)
django-compressor (1.6)
django-extensions (1.6.1)
django-filer (0.9.12)
django-flat-theme (1.1.3)
django-hvad (1.4.0)
django-mptt (0.8.0)
django-multiselectfield (0.1.3)
django-polymorphic (0.7.2)
django-rosetta (0.7.8)
djrill (2.0)
docopt (0.4.0)
easy-thumbnails (2.2)
ecdsa (0.13)
Fabric (1.10.2)
feedparser (5.2.1)
FeinCMS (1.11.4)
mandrill (1.0.57)
microsofttranslator (0.7)
MySQL-python (1.2.5)
paramiko (1.16.0)
path.py (8.1.2)
Pillow (2.6.1)
pip (8.0.2)
polib (1.0.7)
pycrypto (2.6.1)
pytz (2015.7)
requests (2.9.1)
setuptools (11.0)
six (1.10.0)
solid-i18n (1.1.1)
Unidecode (0.4.18)

Voor de webapps in PHP, volstond het om de expiratiedatum van de cookie in de toekomst te zetten. Helaas gaat die vlieger niet op voor Django. Is er iemand die dit probleem ook tegen is gekomen en heeft opgelost? Of heeft iemand nog een goede tip?

[Janoz]

Probeer eens het request te bekijken wat je binnen krijgt van de iPad. Let daarbij op of je daadwerkelijk de cookie ook binnenkrijgt. Op dit manier is iig beter te bepalen of het probleem bij de iPad ligt (de cookie blijft bv niet bewaard) of aan de serverkant (cookie komt wel maar de hash is niet meer geldig ofzo)

[VTe]

Ik ben er inmiddels achter dat het probleem waarschijnlijk schuilt in het gebruik van een eigen User model. Wanneer ik gebruik maak van de standaard authenticatie in Django, werkt alles naar behoren

[deadinspace]

VTe schreef op dinsdag 26 januari 2016 @ 22:01:
Ik ben er inmiddels achter dat het probleem waarschijnlijk schuilt in het gebruik van een eigen User model. Wanneer ik gebruik maak van de standaard authenticatie in Django, werkt alles naar behoren

Hoe en waarom gebruik je een eigen User model?

Heb je ook al gedaan wat Janoz zei: kijken of de cookie daadwerkelijk correct wordt meegestuurd?

[VTe]

Ik heb dinsdag gekeken naar de inhoud van request.COOKIES, daar zit een geldige session ID in. Ik had aan het einde van de dag even geen tijd meer om te kijken wat de middleware van Django doet met de meegestuurde session ID.

Voor het betreft het User model: we moeten gebruikers laten inloggen door middel van een emailadres EN we moeten aanvullende informatie bij de gebruiker opslaan. Ik heb dus volgens de documentatie een nieuwe class gemaakt die een subclass is van AbstractBaseUser.

Ik ga morgen nogmaals rondneuzen!

[VTe]

Waar het precies fout gaat is nog niet bekend, maar ik heb inmiddels een oplossing die (voorlopig) werkt. Op de view voor de homepage stond de 'login_required' decorator ingesteld. Ik vermoed dat de redirects van decorator roet in het eten gooien, in ieder geval op een standalone webapp. De decorator heb ik verwijderd en in plaats daarvan een controle op request.user.is_authenticated() toegevoegd. Indien deze faalt, laat ik de login-template zien zodat de gebruiker kan inloggen. Hierna komt de gebruiker weer terug op de homepage en kan hij/zij de webapp gebruiken.

Het geforceerd sluiten van de app werkt nu ook, dus het lijkt erop dat de cookie ook gewoon goed wordt aangeboden.

Edit: eigenlijk was er geen probleem, maar deed ik een verkeerde aanname. Om nog even uit mijn tekst op StackOverflow te putten:

I don't know if I should feel stupid or not, but the issue is solved. I was using the @login_required decorator on the homepage view. Loading the webapp from a blank/new session would redirect the homepage (/) to <domain>/login/?next=/. So, when opening the webapp in Safari and adding it to the homescreen, would also set webapp url to <domain>/login/?next=/. But, this page always shows the loginform, regardless if you are logged in already. I wrongfully assumed that it would redirect you to the page that was set in the next variable. But since a homescreenapp without a manifest file always reloads the URL that it was saved with, you would always see the loginform.

[ Voor 37% gewijzigd door VTe op 31-01-2016 14:07 . Reden: Aanvulling op de oplossing ]