Migrate to dreamjub for authentication #26
Comments
|
We should wait for dreamjub to at least have an endpoint that exposes all users to do this. That way we can completely migrate to dreamjub and ditch the old API entirely. |
|
This API is now available—however there is pagination, which limits results to 1000 at a time. We could either pull users 1000 at a time, and loop, or add another endpoint to dreamjub for this purpose |
kuboschek
added a commit
that referenced
this issue
Mar 10, 2017
tkw1536
pushed a commit
that referenced
this issue
Oct 13, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 13, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 14, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 14, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 14, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 14, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 14, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Oct 30, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore user data was also received from this API. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on a legacy system. This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore, user data was also received from this API and evaluated using a custom JavaScript bridge. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on two legacy systems, the OpenJUB API and the memory intensive JavaScript evaluation of filters This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. Furthermore, we also migrate the evaluation of filters to use a python-based evaluation, which no longer needs a JavaScript runtime on the server side. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore, user data was also received from this API and evaluated using a custom JavaScript bridge. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on two legacy systems, the OpenJUB API and the memory intensive JavaScript evaluation of filters This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. Furthermore, we also migrate the evaluation of filters to use a python-based evaluation, which no longer needs a JavaScript runtime on the server side. See also issue #26.
tkw1536
pushed a commit
that referenced
this issue
Nov 1, 2017
Previously, authentication worked by transmitting the password to the legacy OpenJUB API. Furthermore, user data was also received from this API and evaluated using a custom JavaScript bridge. This caused problem, as Jay was able potentially able to intercept user passwords and also depended on two legacy systems, the OpenJUB API and the memory intensive JavaScript evaluation of filters This commit updates the authentication to use the new dreamjub api via OAuth. Furthermore, it updates the permission system to move away from UserProfiles and SuperAdmin models. Instead, this commit makes use of internal Django mechanisms and stores user data directly with the model. Furthermore, we also migrate the evaluation of filters to use a python-based evaluation, which no longer needs a JavaScript runtime on the server side. See also issue #26.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the voting system uses the legacy OpenJUB API for login.
A solution to this issue uses dreamjub's OAuth for user authentication.
I've already written a login provider for django-allauth, it's basically plug and play
The text was updated successfully, but these errors were encountered: