Aha, the trick is to use notify: false in the success event. So, like
before:
$rootScope.$on '$stateChangeStart', (event, toState, toParams)->
if toState.authorize?
event.preventDefault()
toState.authorize(toParams).then (val)->
if val == false
$state.go 'error'
else
$state.go toState, toParams, {notify: false}
which will go to that state we were originally visiting, except without
firing stateChangeStart events. Not bad.
On Fri, Jul 18, 2014 at 1:37 PM, Eric Eslinger <[email protected]>
wrote:
> Short story: I want to do some state change approval to make sure users
> don't get into the wrong state, and I want to do that asynchronously,
> similarly to a connect middleware model. Something like:
>
> $rootScope.$on '$stateChangeStart', (event, toState, toParams)->
> if toState.authorize?
> toState.authorize(toParams).then (val)->
> if val == false
> event.preventDefault()
> $state.go 'error'
> else
> event.next()
>
> Which, of course doesn't work. It looks like the way the event goes, if I
> don't call event.preventDefault() synchronously, I don't prevent the state
> change. But I don't know if the state change is allowed until after the
> promise permissions-check promise resolves.
>
> Has anyone tried to get this working? I'm thinking about some complex and
> annoying flags. Something like - always call preventDefault if there's an
> authorize block and the state params don't have an authorizePrecheck ==
> true. Then if the promise resolves good, set toParams.authorizePrecheck =
> true and call $state.go toState, toParams
>
> That seems a bit unwieldy, but would probably work (I'll check that in a
> bit). Is there a strategy I hadn't thought of?
>
> I know that I *could* change how my checkPermissions function works and
> throw an error, then put the authorization code in the resolve block of
> each state, then listen on $stateChangeError, and that's a possibility as
> well. It's just that I have a ton of permissioned states and this seemed to
> be a bit smarter - DRYer if nothing else.
>
> Eric
>
> PS: this is all convenience, by the way. the actual authorization code
> also runs on the server, but this helps users who click constructed URLs or
> bookmarks to pages know that they're in a place that they're 403 for.
> Otherwise, they'd get weirdly-behaving pages in general, as the server
> threw 403s on the XHR requests associated with saving the edited document
> or whatever.
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
