Re: [Wonder-disc] A ponder startup question?

[Ramsey G. <rg...@sm...>]

Oh, one thing I forgot. You'll probably need to go into your database and add some challenge questions before you can create your first user. You'll need at least 3 by default.  Thinking of good challenge questions is hard, so I didn't let users do that for themselves.

On Nov 30, 2012, at 11:41 AM, Ramsey Gurley wrote:

> 
> On Nov 30, 2012, at 10:19 AM, James Cicenia wrote:
> 
>> Hi -
>> 
>> I have everything "running." 
>> 
>> Well at least my new project references a half dozen frameworks successfully with all migrations.
>> I changed some of your migration code to work with MySQL. But other than that, it mostly worked.
> 
> I'm curious, what needed to be changed to work with MySQL?
> 
>> 
>> Now my big question. How do I get in?
>> 
>> I am trying to get a login/create / account page to show up. I am assuming you have this wired
>> to come up via D2W? I can get the normal "Main" to show up no problem. But how do you address
>> this? How do you wire it into your auth?
>> 
>> Thanks
>> James
> 
> 
> The crudAuthorization object decides everything. In the ERUsers rules you'll see
> 
> 10 : entity.model.name = 'ERUsers' => crudAuthorization = "er.users.delegates.AuthorizationDelegate.INSTANCE" [ERDEnumAssignment]
> 
> I believe that default allows anyone to create a user. ERUsers provides this via the NavigationMenu.plist in the framework. You can add the "Login" navigation item somewhere in your app's NavigationMenu.plist like, 
> 
> (
> 	{
> 		name = Root;
> 		children = (ItemOne,ItemTwo,ItemThree,Login);
> 	},
> …
> )
> 
> Then when you click login, you should get a login form and a create user link. To create a user, you'll need to have your javamail properties set up. Creating a user validates the email address by sending the user an email with a link to click. Or you can just go into your database and copy/paste the url from the email clob into your browser.
> 
> Anyway, once you create a user, you could give that user super powers by 
> 
> 100 : session.objectStore.user.username = 'jcicenia' => crudAuthorization = "er.auth.SimpleCRUDAuthorization.ALLOW_ALL" [ERDEnumAssignment]
> 
> This would let you create some ERRoles using a direct action like:
> 
> /wa/CreateERRole
> 
> Of course, ERRole is just an id and a name, so you could do that in your DB admin tool really quickly if you prefer.
> 
> Once you have some roles, you can relate users to roles with the provided many-to-many relationship.  Then you just have to set up permissions on the roles.  Let's say you have an EO named Widget, then you can
> 
> /wa/AuthorizeWidget
> 
> to get a role based authorization page for that kind of EO.  It's a lot of checkboxes, but the usage should be pretty obvious. 
> 
> Once you've set up permissions on the roles, you should be able to enforce them with the er.auth.RoleBasedCRUDAuthorization as your crudAuthorization in the rules. You'd probably want to stash these on the session or something since ERDDelayedObjectCreationAssignment would create a new one every time its called and the crudAuthorization would be getting called a lot.  The others are Enums so they don't have this problem.
> 
> That one is not an Enum, because you might want to subclass it to give fine grained control over authorization. Ex. A doctor may have access to medical records in general, but may not have access to Mary Scott's medical record for some reason. The subclass provides a place to override the role values and inject all the horrible custom logic that is typically required in these matters.
> 
> One other thing that might not be immediately obvious is that you can specify authorizations for a specific EO by making a method with that entity's class as an argument. The ERASelector does this. 
> 
> So, for example, instead of having a ton of branch logic in one method like
> 
> public Boolean canReadProperty(EOEnterpriseObject eo, String keypath) {
> 	if(eo instanceof ERUser) {
> 		//do something special
> 	} else {
> 		//do something else
> 	}
> }
> 
> you can do
> 
> public Boolean canReadProperty(EOEnterpriseObject eo, String keypath) {
> 	//do something else
> }
> 
> public Boolean canReadProperty(ERUser eo, String keypath) {
> 	//do something special
> }
> 
> And it will pick the right method for the type of EO. Much cleaner/easier to read. This will only work with classes though, it won't work with interfaces. The most specific subclass of EOEnterpriseObject is selected. If none are found the EOEnterpriseObject method is used as the fallback. 
> 
> The same sort of thing can be applied to methods that don't have an EO instance using the clazz pattern. EOGen templates for this are provided in the ponder support folder. Look at the er.users.delegates.AuthorizationDelegate for more examples.
> 
> That should be enough to keep you busy for a while :-)
> 
> Ramsey
> 
>