Thanks!

That cleared it all up for me. I guess I misunderstood how this was
supposed to work. It appears that all of my broadcasts and views
happened even if the event would ultimately just display the login
screen. My events that were working were simple and the views and
broadcasts weren't dependent on values that didn't exist due to the
user not actually being logged in. This now makes sense. I do kinda
wish there was a way to tell MG to stop processing broadcasts/views
without actually doing a full redirect... but that is kinda minor and
I can work with this.

Thanks again Ezra!

Jeremy

On Oct 19, 3:43 pm, Ezra Parker <[email protected]> wrote:
> Hi Jeremy,
>
> Adding a redirect attribute to the result tags in your event type
> should cause this to work as intended:
>
> <result name="NotLoggedIn" do="user.login" redirect="true" />
> <result name="InvalidRole" do="user.noPrivs" redirect="true" />
>
> HTH,
>
> --
> Ezra Parker
>
>
>
> On Mon, Oct 19, 2009 at 12:31 PM, Jeremy Prevost <[email protected]> wrote:
>
> > I'm using event types for security. I have several different Event
> > types that correspond to various roles. In those types are <before>
> > blocks that check the role required for the event.
>
> > Here's an example:
>
> >                <event-type name="requireStaff">
> >                    <before>
> >                        <broadcasts>
> >                                <message name="CheckRole">
> >                                        <argument name="requiredRole" 
> > value="staff" />
> >                                        </message>
> >                            </broadcasts>
> >                        <results>
> >                            <result name="NotLoggedIn" do="user.login" />
> >                            <result name="InvalidRole" do="user.noPrivs" />
> >                        </results>
> >                    </before>
> >                </event-type>
>
> > For most events, adding a type="requireStaff" works as expected (if
> > not logged in, user.login runs). Invalid role runs user.noPrivs. If
> > all is well the event continues. Here's an example of a working event:
>
> >                <event-handler name="admin.index" type="requireStaff">
> >                        <broadcasts>
> >                        </broadcasts>
> >                        <results>
> >                                <result do="admin.template" />
> >                        </results>
> >                        <views>
> >                                <include name="body" 
> > template="admin/dspAdminIndex.cfm" />
> >                        </views>
> >                </event-handler>
>
> > However, I have other events that don't seem special to me in any way
> > where I define the type the same way and it ignores the security and
> > just keeps on trucking through the event. Here's an example of an
> > event that isn't working correctly.
>
> >                <event-handler name="lists.indexCurrentUser" 
> > type="requireStaff">
> >                        <broadcasts>
> >                                <message name="needMySharesList" />
> >                                <message name="needMyShares" />
> >                                <message name="needMyPreferredList" />
> >                                <message name="needPopularTags" />
> >                        </broadcasts>
> >                        <results>
> >                                <result do="view.templateSidenav" />
> >                        </results>
> >                        <views>
> >                                <include name="body" 
> > template="lists/dspIndex.cfm" />
> >                        </views>
> >                </event-handler>
>
> > From what I can tell, the checkRole function runs and the logic that
> > sets NotLoggedIn is being triggered but user.login never fires. Again,
> > this is only for certain events... most are working fine which is what
> > is driving me crazy. Any suggestions as to what may be going on would
> > be much appreciated.
>
> > I was using MG 3.0 and just updated to 3.1 and the problem persists.
>
> > Thanks!
> > Jeremy
--~--~---------~--~----~------------~-------~--~----~
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog

You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to