Skip to content
This repository has been archived by the owner on Oct 22, 2019. It is now read-only.

Signup redirect url parameter #530

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Rsgm
Copy link

@Rsgm Rsgm commented Aug 12, 2016

This works the same as the signin redirect. If a user was trying to access a page and gets redirected to sign in or sign up, after succeeding they will be redirected from where they came.

Since a user can only be redirected to either the signin or signup page, it is beyond the scope of this feature to pass the query parameter in the url to the other page when requested.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.04%) to 95.62% when pulling 9326082 on Rsgm:signup-redirect into 6cc0954 on bread-and-pepper:master.

@Rsgm
Copy link
Author

Rsgm commented Aug 17, 2016

I just realized signin form sends the next field as a post field. I will close this and update signup to act more like that.

@Rsgm Rsgm closed this Aug 17, 2016
@Rsgm
Copy link
Author

Rsgm commented Aug 18, 2016

I added next as a post parameter. It reflects how signin works with redirect parameters. I didn't add much else, but I fixed a bug with the old one.

There really isn't a reason to send the redirect url as a post parameter. The post parameter comes from the initial url parameter, which gets sent through a post request anyway.

I am not sure why a few tests fail.

@Rsgm Rsgm reopened this Aug 18, 2016
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 95.543% when pulling 4c038a0 on Rsgm:signup-redirect into 6cc0954 on bread-and-pepper:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 95.543% when pulling 4c038a0 on Rsgm:signup-redirect into 6cc0954 on bread-and-pepper:master.

@swistakm
Copy link
Contributor

@Rsgm yeah, sending this redirect value additionally through POST form seems pretty odd at first glance. But after some thought I guess it is designed that way to make whole solution more robust against subtle errors/mistakes made often by developers.

Consider a case when userena user overrides "sing in" template with something like following:

<form action="/accounts/signin/" method="post">
{{form.as_p}}
{# ... #}
</form>

This way you could accidentally disable whole redirection feature by using action="/accounts/signin/" instead of leaving this attribute empty. Form would work OK but would not redirect to next as expected. The same would happen if you would like to use {% url your_sign_in_view %} template tag. By adding redirection url as a hidden form field (back from query string) we are able to cover few cases of such very subtle issues that are not always obvious.

I won't argue if silently dealing with such cases is bad or good. It is great that you choose the approach that is consistent with the one that we have already have in "sign in" flow because it will be less surprising to users.

Now back to the PR. I will try to reproduce errors we see on Travis in my local environment. I have tried already to rerun tests in Travis and I'm pretty sure it is not a random failure. Anyway, it is interesting that some tests fail only on py32-django17 and py32-django18. Have you tried to reproduce these errors in your local environment?

@Rsgm
Copy link
Author

Rsgm commented Aug 22, 2016

Thank you for the explanation. I guess I didn't know forms without an action use the current url. I agree, that is probably a good check to have.

As for the tests. I only tested it on 2.7 and 3+, since I knew Travis would check the rest. I will try on my machine with all the versions though.

I apologize for the coverage going down. I did add a test, but unit tests can't really reflect this functionality well.

Last thing. I wasn't sure if this would fit in the scope of this project, but there is no real way to do it from outside of the app. Hopefully others find it useful too.

@swistakm
Copy link
Contributor

The #535 was the reason of failures in CI and was stopping this PR from merging. Fortunately, it is finally resolved. Could you rebase your PR on current master so we can have it tested in Travis again?

When doing rebase you can also squash your changes in order to keep commit log more concise.

This works the same as the signin redirect. If a user was trying
to access a page and gets redirected to sign in or sign up,
after succeeding they will be redirected from where they came.

Since a user can only be redirected to either the signin or signup
page, it is beyond the scope of this feature to pass the query
parameter in the url to the other page when requested.

Updated signup redirect to work like signin

Added signup redirect for SIGNIN_AFTER_SIGNUP
@Rsgm
Copy link
Author

Rsgm commented Aug 29, 2016

I apologize, I only just got around to fixing my branch. I updated this and my other previous merge request. Assuming everything passes, the previous request(#515) may need to be merged before this(I am certain how branches merge with the same commit).

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 95.543% when pulling 2f35219 on Rsgm:signup-redirect into 7dfb3d5 on bread-and-pepper:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 95.543% when pulling 2f35219 on Rsgm:signup-redirect into 7dfb3d5 on bread-and-pepper:master.

@Rsgm
Copy link
Author

Rsgm commented Aug 30, 2016

The travis error is looks like it is failing trying to set up the environment. It also failed a different python/django version on my other pull request, #515.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants