-
-
Notifications
You must be signed in to change notification settings - Fork 514
Flask-Login 0.1.3 removed from PyPI #123
Comments
I'm working on updating to 0.2.2 but there's an issue sometimes where the |
I noticed this issue as well trying to patch Flask-Security. It may be a problem in Flask-Login. |
It looks like |
I'm pretty sure it's in Flask-Login. When using 0.2.1 the same couple of tests fail but the exception is raised from within |
What happens if yo hot-patch Flask-Login with this? def _load_from_cookie(self, cookie):
if self.token_callback:
user = self.token_callback(cookie)
if user is not None:
session['user_id'] = user.get_id()
session['_fresh'] = False
_request_ctx_stack.top.user = user
else:
self.reload_user()
else:
user_id = decode_cookie(cookie)
if user_id is not None:
session['user_id'] = user_id
session['_fresh'] = False
self.reload_user() |
The tests in suspect in regards to that function are now fixed. Looks like the flash message category was changed so thats just a test change on my side. |
All tests pass now. Thanks for the quick response on this. |
Okay so I think I need to do a release updating that method then. Will that fix things for you as far as Flask-Login? |
Yes, that would be greatly appreciated. |
No problem, 0.2.3 should be on PyPI now. |
- Improve documentation for :meth:`.UserDatastore.create_user` to make clear that hashed password should be passed in. - Improve documentation for :class:`.UserDatastore` and :func:`.verify_and_update_password` to make clear that caller must commit changers to DB if using a session based datastore. - (:issue:`122`) Clarify when to use ``confirm_register_form`` rather than ``register_form``. - Fix bug in 2FA that didn't commit DB after using `verify_and_update_password`. - Fix bug(s) in UserDatastore where changes to user ``active`` flag weren't being added to DB. closes: pallets-eco#122
Hi,
I'm sorry to report that earlier today I was forced to reset the PyPI index for Flask-Login in order to resolve an issue with downloads.
A side effect of this is we lost a release that was never tagged: 0.1.3. It's unclear how 0.1.3 originally made it out to PyPI but it should never have been there given it wasn't a tagged release.
Naturally this is going to break applications that are looking for 0.1.3 on PyPI. I believe 0.1.3 may have either been a duplicate or a close cousin of 0.1.2 so I think it would be advisable to use 0.1.2 in its place (or where possible use 0.2.x; while I understand that isn't yet possible here).
The text was updated successfully, but these errors were encountered: