-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The current SESSION_EXPIRED
mechanism is too rigid
#67
Comments
Also expose IsSessionExpiredException so consumers could define their own evaluator which they in turn could use to set up the OAuth module itself. All exceptions are then passed to this evaluator so nothing falls through the cracks. #67
Hey, However I think since it can be worked around it would be good to keep backward compatibility so existing workarounds don't break, they just become deprecated. |
Yeah, I've had this on my todo list as well for a good while now, didn't have time to file a PR for it until now. 🙂 I wasn't aware of any workaround, but I'm pretty sure it'll break it as I changed the method signatures in |
The current
SESSION_EXPIRED
mechanism can only be triggered if aretrofit2.HttpException
is thrown, therefore when using this library in combination withRetrofit-Error-Parsing
, which throws its own custom exception (NetworkException), theSESSION_EXPIRED
mechanism simply gets bypassed, resulting in the consumer not being informed about the incident (instead of being logged out, users would remain logged in and being shown errors for any attempt of accessing remote resources).The text was updated successfully, but these errors were encountered: