Skip to content
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

Do not run prefilter actions if authorizer is destroyed. #191

Closed

Conversation

wbyoung
Copy link
Contributor

@wbyoung wbyoung commented Jun 15, 2014

This probably wouldn't affect a production application, but in testing if you create new containers to test with (or if you reset your application), you could end up with many pre-filters set up. Since there's no way to remove a pre-filter, I think this is a good way to keep them from running once the authorizer and container are no longer in use.

@@ -138,6 +138,7 @@ var setup = function(container, application, options) {
if (!!authorizer) {
authorizer.set('session', session);
Ember.$.ajaxPrefilter(function(options, originalOptions, jqXHR) {
if (authorizer.isDestroyed) { return; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd move that to line 138

if (!!authorizer && !authorizer.isDestroyed) {

Can you also add a test for that?

@wbyoung
Copy link
Contributor Author

wbyoung commented Jun 16, 2014

@marcoow that line can't be move there. The check is to ensure that while the pre-filter is still installed, that it doesn't actually do anything when the authorizer has been destroyed.

I've pushed an integration test to cover this. I didn't want to mock anything out, so I had to use a private call to __container__ to set things up, but this seems to be a pretty common practice in tests.

As a separate note, the pre-filter is capturing the authorizer within its scope. This means that each time you call setup, you'll have a new pre-filter with an authorizer captured within it. This authorizer probably holds on to a reference to the entire container in some way, so eventually you could end up with a decent amount of memory growth as objects would never be freed. But since in production, you'd really only ever call setup once, this really doesn't matter much.

@marcoow
Copy link
Member

marcoow commented Jun 17, 2014

Ah sorry, you're right.

Can you create a simple test here though and just mock the isDestroyed property on the authorizer?

@wbyoung
Copy link
Contributor Author

wbyoung commented Jun 17, 2014

@marcoow done.

@marcoow
Copy link
Member

marcoow commented Jun 17, 2014

Cool, the integration test isn't really needed then though.

@wbyoung
Copy link
Contributor Author

wbyoung commented Jun 17, 2014

@marcoow ok, I removed it.

@marcoow marcoow added this to the 0.5.4 milestone Jun 17, 2014
@marcoow
Copy link
Member

marcoow commented Jun 17, 2014

merged: 5b71680

@marcoow marcoow closed this Jun 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants