Closed everhoej closed 8 years ago
We do not carry the 'Locked' attribute with us.. I think the correct thing to do would be to deny login and add a message header that indicates that its because the user has been locked.. The player should then redirect the user to the login page on E17 where the user can go through the normal 'change password' flow.
@simmoe what do you say?
Another option could be using the dialog parts of DODP to prompt the user for a new password, but I am not sure if it is possbile.
That is not possible, dynamic menus are only available when there is an active session (the user has logged in). It would require substantial hacking to introduce a meta-state in the DODP stack which would allow certain requests in a semi-logged-in state..
I think the best option would be to build a webservice a'la the CatalogSearch services, which could expose a method for either ordering a new temporary codeword or setting a new password..
..Naturally, there is nothing that prevents us from implementing this service method on the actual DodpMobile webservice, in the part of the service that is specific to handling mobile services..
I think the last mentioned seems to be a good idea - it seems natural that users should be given the option to select a new password here, and it won't break the dodp protocol
Den 15/05/2013 kl. 10.43 skrev Henrik Witt-Hansen notifications@github.com:
That is not possible, dynamic menus are only available when there is an active session (the user has logged in). It would require substantial hacking to introduce a meta-state in the DODP stack which would allow certain requests in a semi-logged-in state..
I think the best option would be to build a webservice a'la the CatalogSearch services, which could expose a method for either ordering a new temporary codeword or setting a new password..
..Naturally, there is nothing that prevents us from implementing this service method on the actual DodpMobile webservice, in the part of the service that is specific to handling mobile services..
— Reply to this email directly or view it on GitHub.
Not a player issue any longer, since the login page has been redirected to Nota.dk
Today it is possible to log in with a "midlertidigt kodeord" on E17 Direkte without being asked to change it or being directed to E17 to change it. This way the user can actually log in and listen to books with a "midlertidigt kodeord".
The right flow would be to direct the user who log in with a "midlertidigt kodeord", to a new page on the player where they can change their password.