2011年2月28日星期一

Re: [fw-mvc] Zend framework ACL - newbie help needed

-- Rishi Daryanani <rishijd@yahoo.com> wrote
(on Monday, 28 February 2011, 06:06 AM -0800):
> I'm very new to ACL and it's not something we've tried below. Any guidance would
> be appreciated; I'm going to start with code experimentation but would like to
> know if I'm on the right track.
>
>
> We are using a custom developed CMS which is using ZF", and we have our front
> end website as well. The CMS uses a controller called "AdminController", and the
> front end only uses a controller called "IndexController". I want to introduce
> access control to this CMS. Therefore some user groups will be restricted to
> some areas of the CMS.
>
> Current potential solution :
>
> I'm thinking of achieving this functionality as described below.
>
> 1. Have a database table to store the type of the user.
> 2. Have a separate table to store the pages the user is allowed or not allowed.
> 3. Check in each page whether the user have the access or not and display the
> page accordingly.
>
> Which is the best way to implement this using Zend framework? "Zend_Auth" or
> "Zend_Acl" ?

Zend_Auth is used for authentication of a user; i.e., evaluating the
provided credentials to determine identity.

Zend_Acl is used for authorization; i.e., to determine whether a given
user has the rights to access a given resource.

What you describe above is the realm of Zend_Acl.

> I have looked in to the "Zend_Acl" and it sounds good, however
> could someone guide me - what is the procedure for implementing this? Here are
> the links I found:
> http://framework.zend.com/manual/en/zend.acl.introduction.html
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=39025

The basic workflow is:

* Create a Zend_Acl object
* Add roles to the Zend_Acl object
* Add resources to the Zend_Acl object
* Create the permissions

Now, that said, there are a variety of ways to do this. You can do it
up-front -- i.e., define all roles, resources, and permissions in a
given object or in your bootstrap. If you have only a handful of ACLs to
create, this is a straight-forward approach.

Another approach is to add them as you need them.

As an example, when you grab the user identity during login or later
from the Zend_Auth session container, you might include the role in the
identity information. You can then add this to the ACL as you grab it:

$acl->addRole($identity->role);

You could also define an array of roles, and then one master role for
the user (which would indicate the user inherits all of those roles):

foreach ($identity->roles as $role) {
$acl->addRole($role);
}
$acl->addRole($identity->username, $identity->roles);

Later, when you grab your page, you might also include ACL information
in the page metadata. This allows you to setup the resource and
permissions ad-hoc. As an example, let's assume that a "page" object
might have the following in its structure:

public $identifier;
public $roles = array(
array('role' => array('read', 'write'))
);

$acl->addResource($page->identifier);
foreach ($page->roles as $role => $rights) {
if (!$acl->hasRole($role)) {
$acl->addRole($role);
}
$acl->allow($role, $page->identifier, $rights);
}

Then, you can test right there and then:

if (!$acl->isAllowed($identity->role, $page->identifier, $currentPrivilege)) {
throw new AclException;
}

This allows you some flexibility -- you don't have to define all ACLs up
front, and can grow the graph as your content grows. That said, it can
get tricky if you want to introduce role inheritance, so you have to
setup a strict convention of how the roles are stored.

Hope that helps get you started!

> The gist of my understanding is:
> - In the AdminController (or is it bootstrap.php) I have to define a set of
> Roles and Resources that are accessed/denied for those roles. This follows the
> above tutorial example. In my case, I need to add a new user role called "staff
> user" who will just have access to one function in the CMS, a basic "customer
> lookup" reporting function.
>
> - However I also need to check (in the "customer lookup" function) if the
> logged-in user has access rights to view this page. In all other pages, I need
> to DENY access rights actually, if the logged in user is a "staff user". Is
> there a tutorial like this which explains it for newbies? Or could someone guide
> me on what kind of code goes where?
>
> I'm not sure how I can tell ZF the name of the resource of each section/function
> of the CMS. For example, if I have a section called "Reports", and functions
> called
> - "Customer Lookup"
> - "Orders report"
> - "Members report"
>
> then what code would I put in for each of the above controller functions to
> assign a resource name and possibly a module/sub-resource name to each function?
>
> Many thanks,
> Rishi
>
>
>

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

[fw-mvc] Zend framework ACL - newbie help needed

Hi,

I'm very new to ACL and it's not something we've tried below. Any guidance would
be appreciated; I'm going to start with code experimentation but would like to
know if I'm on the right track.


We are using a custom developed CMS which is using ZF", and we have our front
end website as well. The CMS uses a controller called "AdminController", and the
front end only uses a controller called "IndexController". I want to introduce
access control to this CMS. Therefore some user groups will be restricted to
some areas of the CMS.

Current potential solution :

I'm thinking of achieving this functionality as described below.

1. Have a database table to store the type of the user.
2. Have a separate table to store the pages the user is allowed or not allowed.
3. Check in each page whether the user have the access or not and display the
page accordingly.

Which is the best way to implement this using Zend framework? "Zend_Auth" or
"Zend_Acl" ? I have looked in to the "Zend_Acl" and it sounds good, however
could someone guide me - what is the procedure for implementing this? Here are
the links I found:
http://framework.zend.com/manual/en/zend.acl.introduction.html
http://framework.zend.com/wiki/pages/viewpage.action?pageId=39025

The gist of my understanding is:
- In the AdminController (or is it bootstrap.php) I have to define a set of
Roles and Resources that are accessed/denied for those roles. This follows the
above tutorial example. In my case, I need to add a new user role called "staff
user" who will just have access to one function in the CMS, a basic "customer
lookup" reporting function.

- However I also need to check (in the "customer lookup" function) if the
logged-in user has access rights to view this page. In all other pages, I need
to DENY access rights actually, if the logged in user is a "staff user". Is
there a tutorial like this which explains it for newbies? Or could someone guide
me on what kind of code goes where?

I'm not sure how I can tell ZF the name of the resource of each section/function
of the CMS. For example, if I have a section called "Reports", and functions
called
- "Customer Lookup"
- "Orders report"
- "Members report"

then what code would I put in for each of the above controller functions to
assign a resource name and possibly a module/sub-resource name to each function?

Many thanks,
Rishi

2011年2月25日星期五

Re: [fw-db] Zend_Db_Table Issue

On Thu, Feb 24, 2011 at 6:40 PM, Bill Karwin <bill@karwin.com> wrote:

>
> On Feb 24, 2011, at 1:55 PM, David Mintz wrote:
>
> Thanks for the helpful observations. The trouble with NULL is that it's
>> too vague. I have cases where I need something that means "not applicable,"
>> "unknown," or most often, "we don't care" because the proceeding took place
>> before the generic duty magistrate whose actual identity really isn't
>> important, and users don't want to be forced to identify her/him by name.
>>
>
> Fair enough. For what it's worth, it has been a subject of debate over
> many years among relational theorists whether NULL should be a single value
> or should there be multiple "types" of NULL for different purposes. E.g.
> "applicable but unknown at this time" is different from "inapplicable".
> There have been proposals for up to four different types of NULL-like
> value.
>
> On the other extreme, people like C. J. Date argue strongly that any kind
> of NULL is inappropriate in the relational model.
>
> In your case, I'd still recommend using NULL for the foreign key, simply
> because it solves your issue with -1. The worst solution in my view is to
> use a non-null value to do what NULL is meant to do. Once you start saying,
> "we can't use DRI constraints because..." then IMHO it doesn't matter how
> you finish that sentence, because you've already broken your logical
> database design.
>
> If you still need to distinguish between "n/a", "unknown" or "we don't
> care" then add another column called `why_no_judge` or something.
>
>

Say no more! I'm convinced. I am sort of an enthusiast programmer, a guy
with a non-IT job title who has picked up skills to solve problems in the
workplace (there being no one else in the organization to do it). In my
non-expert opinion this is a situation where you have to do something a
little ugly, that doesn't feel completely right, no matter what. And I think
your solution is less ugly and will work better than what I was going to do.
Thanks.

--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/

2011年2月24日星期四

Re: [fw-gdata] Bad request

Catch the exception and look for the body of it (var_dump if necessary) It
should provide more info about the cause of the exception for the body of
the HttpResponse object.

Cheers,
-Ryan


On Thu, Feb 24, 2011 at 2:53 AM, knasboll <tony@perfectfools.com> wrote:

>
> Please advi
> ce...
> This code below returns
>
> [code:protected] => 400
> [message:protected] => Bad Request
>
> Cannot figure out how to do it, xxx is correct in my code :)
>
> $client = Zend_Gdata_ClientLogin::getHttpClient($email, $password,
> Zend_Gdata_Gapps::AUTH_SERVICE_NAME);
> $service = new Zend_Gdata_Gapps($client, $domain);
>
> $get =
> "https://apps-apis.google.com/a/feeds/emailsettings/2.0/xxx.com/xxx/";
>
> $client->setUri($get);
> $client->request('GET');
> --
> View this message in context:
> http://zend-framework-community.634137.n4.nabble.com/Bad-request-tp3322408p3322408.html
> Sent from the Zend gdata mailing list archive at Nabble.com.
>

Re: [fw-mvc] Sessions and passing them between websites

Hey Thomas,

> idea is to be able to embed a form on another website, and then process that form through Action controllers on a site built using the Zend Framework

Why are sessions required? Can you just have the form on site A POST to
the form on site B?

If you did go this route, any non-valid form handling would happen on
site B, but outside of that you can do this without any sessions.

If it is imperative that site A always display the form including the
in-valid form processing results (error messages, required fields, etc),
then you'll need to find a way to make Site A and site B share
information. If these sites are not sharing the same top level domain
name, this gets harder b/c the session identifier used by Zend_Session
will not be the same (that would require some kind of SSO solution.)

Ultimately, it depends on how complex your solution to be.

-ralph

Re: [fw-db] Zend_Db_Table Issue

On Feb 24, 2011, at 1:55 PM, David Mintz wrote:

> Thanks for the helpful observations. The trouble with NULL is that
> it's too vague. I have cases where I need something that means "not
> applicable," "unknown," or most often, "we don't care" because the
> proceeding took place before the generic duty magistrate whose
> actual identity really isn't important, and users don't want to be
> forced to identify her/him by name.

Fair enough. For what it's worth, it has been a subject of debate
over many years among relational theorists whether NULL should be a
single value or should there be multiple "types" of NULL for different
purposes. E.g. "applicable but unknown at this time" is different
from "inapplicable". There have been proposals for up to four
different types of NULL-like value.

On the other extreme, people like C. J. Date argue strongly that any
kind of NULL is inappropriate in the relational model.

In your case, I'd still recommend using NULL for the foreign key,
simply because it solves your issue with -1. The worst solution in my
view is to use a non-null value to do what NULL is meant to do. Once
you start saying, "we can't use DRI constraints because..." then IMHO
it doesn't matter how you finish that sentence, because you've already
broken your logical database design.

If you still need to distinguish between "n/a", "unknown" or "we don't
care" then add another column called `why_no_judge` or something.

Regards,
Bill Karwin

Re: [fw-db] Zend_Db_Table Issue

On Thu, Feb 24, 2011 at 1:41 PM, Bill Karwin <bill@karwin.com> wrote:

>
> On Feb 24, 2011, at 8:52 AM, David Mintz wrote:
>
> In
>> `events`, my judge_id is signed, and a negative value like -1 means 'not
>> applicable' (to the application) and so forth. At event insertion/update
>> time I will go to great pains to enforce RI, e.g., by locking tables and
>> making sure nobody has deleted judge so-and-so out from under me.
>>
>> What solution would you suggest?
>>
>
> Right -- you can't use -1 if you want DRI, because there is no judge whose
> primary key value is -1.
>
> You should make the judge_id column nullable, and use NULL to mean 'not
> applicable' or 'not assigned'. Then you can declare a foreign key
> constraint to the judges table. A NULL in the foreign key column doesn't
> have to match any row in the referenced table.
>
> You can read more about using NULL in my book "SQL Antipatterns" (
> http://www.pragprog.com/titles/bksqla/), in the chapter "Fear of the
> Unknown."
>
> That said, I think it's weird to delete a row from the judges table
> regardless. Does that mean when a judge retires, you delete his row, and
> the delete cascades to any events that he or she participated in? Doesn't
> that mean destroying a lot of useful historical data? Not to mention
> erasing the legacy of a respectable career in public service?
>
> I would think that in an app like this, you would never actually DELETE a
> row from judges. Instead, you set a `status` attribute for that judge, to
> mark him or her as 'retired' or 'voted out of office' or something. Or else
> set a date field for `end_active_term`. Then code your application logic to
> create new events only for active judges, e.g. those whose `status` is
> 'active', or whose `end_active_term` is either NULL or in the future.
>
> If you don't delete, then you don't need to cascade deletes. :-)
>


Thanks for the helpful observations. The trouble with NULL is that it's too
vague. I have cases where I need something that means "not applicable,"
"unknown," or most often, "we don't care" because the proceeding took place
before the generic duty magistrate whose actual identity really isn't
important, and users don't want to be forced to identify her/him by name.

And you're quite right: deletion will be a rarity in my judges table as well
as most others. But it could happen that one user half-assedly puts in an
inexact duplicate of another row, or otherwise made some mistake, and
someone else comes along and corrects the mistake by deleting it before the
row acquires children, but too late for its id not to appear as a value in
some SELECT menu.

And I do have a de facto boolean 'active' column in this table (it's MySQL)
where 1 means active and 0 means inactive -- retired, deceased, resigned,
etc. Indeed when someone who is known to the app changes hats -- and it
happens -- say from law clerk to prosecutor, prosecutor to judge, they will
not be deleted but made inactive and then they'll be reborn in another row.
I call it reincarnation. Otherwise, yeah, you would trash or falsify your
historical data.

It's really reassuring when someone who knows what he's talking about
suggests you do what you're already doing, so thanks!

Getting back to the first point about NULL, I suppose I could make the data
model even more complicated but I'd of course prefer to keep it as simple as
possible, no more complex than necessary. I'm of course open to more
suggestions, but I think it may be that it's just the challenge of modeling
uncooperative reality in a set of rectangular tables.


--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/