Darrel O'Pry

@rcmurphy any inclination to continue working on this PR or rebased it on master to help keep it current?

I would strongly support an approach that adds allowed origins to application and utilizes decorators on the built in views. I'm not in favor of implementing this as a middleware...

We merged additional CORS work in Fix CORS by passing 'Origin' header to OAuthLib, in https://github.com/jazzband/django-oauth-toolkit/pull/1229. There is an example at https://github.com/jazzband/django-oauth-toolkit/blob/master/tests/app/idp/idp/apps.py of using the coreheaders middleware to set explicit...

I'm closing this as stale and possibly resolved. The `corsheaders.Middleware.CorsMiddleware` from the [django-cors-headers](https://pypi.org/project/django-cors-headers/) package can be configured to apply to routes selectively using the `corsheaders.signals.check_request_enabled` signal. There is an example...

@mumin91 Do you have any time to wrap up this PR?

@luohaoGit this is most likely a bug that needs to be addressed, but LOGIN_URL should work as indicated by @andreasofthings @andreasofthings actually no it doesn't defeat the purpose of the...

This feels like something that should be specified upstream in Django. I don't think this something we an easily generalize in DOT.

@jezdez good to see you around! I'm heartened to see you're finding the time.

closed since we want to remove all mention of the heroku app. I opened https://github.com/jazzband/django-oauth-toolkit/issues/1360 to track the issue.

We would be happy accept a PR for this feature once it is available in OAuthLib. We'll need to wait on upstream to merge it. It looks like there is...