This document is a summary of part two of a presentation on building a web application with the Zend Framework. It covers adding security features like authentication and authorization using Zend_Auth and Zend_Acl. It also discusses using action helpers and layouts to hook into the request dispatch process and create a consistent site-wide layout.

1. My Very First…Model View Controller Web Applicationwith the ZendFramework – Part Deux New York CityZF Meetup

2. Previously… MVC Basics Zend_Controller_Action, Zend_View, view scripts ZF application structure Where do I find file xyz? Database Zend_DB Forms Zend_Form, Zend_Form_Element, Zend_Validate Zend Tool Project set-up tasks simplified

3. Part One  Part Two Finished With User table set-up Registration form completed Added between Part One and Part Two: User home page (home action in UserController) A few more users Extension of Zend_Controller_Action Explanation forthcoming

4. Part Two Security Authentication Authorization ZF Dispatch Process Action helpers Layouts View Helpers (briefly)

5. Step 8: Security Need to make sure non-logged in users can’t see user home page. Should still be able to see user register page and about page. Members should be able to do everything except admin tasks

6. User Access Security General Pattern (not ZF specific) - two components Authentication Verify that a user is who they say they are Authorization Verify that an authenticated user is allowed to do something

7. User Access Security Analogous to getting into a bar: The bouncer authenticates you when he looks at your ID and decides whether it’s real or not The bouncer authorizes you to enter when he sees that your ID says you’re 21, and that you’re not beyond redemption for the night

8. ZF – User Access Security Authentication – Zend_Auth Adapter based authentication, including: Zend_Db (users stored in DB) OpenID LDAP Others Authorization – Zend_Acl Access Control List Your app’s bouncer

9. Zend_Auth Zend_Auth is a class, implements singleton Access singleton auth instance with: Zend_Auth::getInstance() Instance methods for: Is user logged in? - Zend_Auth::hasIdentity() What is user’s identity? – Zend_Auth::getIdentity() Clear identity – Zend_Auth::clearIdentity() Adapter authenticate– Zend_Auth::authenticate($adapter)

10. Zend_Auth Can handle storage of identity Defaults to storage as session variable Coordinates authentication, doesn’t do it Adapters handle actual authentication I.e., user password lookup is handled by MyApp_Auth_Adapter

11. Auth: Deny Guest Access to Home Grab auth instance, test for identity: If identity, user is logged in If not, user is guest, redirect to login Note, no need for adapter here as we’re not performing authentication

12. Auth: Use of Adapters for Login Redirect logged in user home. Process login attempt.

13. Db Adapter: Setup Constructor needs Db adapter Name of table Name of ID column (i.e. user name, email) Name of credential column (i.e. password)

14. Db Adapter: Setup Pass in posted email and password setIdentity – Tell the adapter the identity the user is trying to log in with. setCredential – Tell the adapter the credential the user is trying to log in with.

15. Db Adapter: Authenticate… Well, kind of Don’t use adapter’s authentication method directly, use Zend_Auth::authenticate and pass the adapter Let’s Zend_Auth store identity in session

16. Auth: Authentication Successful? Zend_Auth::authenticate returns instance of Zend_Auth_Result Use Zend_Auth_Result::isValid to determine success or failure Zend_Auth_Result:: getCodeto get details (useful on auth failure)

17. Auth Accomplished! We can now control access based on log in status! Good enough for simple access control needs: Any user has access to home action No guest has access to home action

18. Auth Accomplished? What about something like delete user action? Being logged in isn’t good enough Would like to base decision on information about the user Is this user an admin? Is this user a plain vanilla user?

19. Auth Accomplished…But Not Authorization What we’re asking is: does this authenticated user have permission to do this thing? This isn’t the responsibility of auth Authorization is the process of determining if a user has access to do an action. Generally, two steps: Determine type of user Ask if that type of user is allowed to perform the requested action (delete a user, edit a task, etc)

20. Authorization: Zend_Acl ZF has Access Control List component Effectively, table of rules for access Rules can be specified flexibly and hierarchically One of ZF’s best components

21. Access Control Concepts Role – user access level (your role in a system) Resource – a thing a user requests access to Privilege – describes an action a user may perform on a resource Roles and resources can be hierarchical Member inherits privileges from guest Admin inherits privileges from member

22. Zend_Acl Access control list is an object. Four steps to configure Create object Add roles Add resources Set rules Query acl using Zend_Acl::isAllowed()

23. TaskMaster Access Control Roles Start with 4 roles, must be declared in advance: Guest Member, inherits from guest Staff, inherits from member Admin, inherits from Staff

24. TaskMaster Access Control Resources Strategy: One controller = one resource One action = one privilege Doesn’t have to be done this way, but is often sensible and convenient later on. 3 Resources, do need to be declared in advance User Task Index Privileges don’t need to be declared in advance

25. ACL Creation: Roles and Resources Add roles and resources first Exception thrown if an unregistered role or resource is referred to:

26. ACL Configuration: Create Rules “Rules” tell the ACL when to allow/deny a user access to a resource “Allow members to edit their info” “Don’t let members delete other members” “Allow an admin to do anything” Syntax: $acl->allow/deny($user, $resource, $privilege) Parameters are flexible, see ZF reference

27. ACL Configuration: Rules Allow the admin all privileges on all resources Deny guest all privileges on all resources Note that this denies all privileges for anyone who inherits from guest as well (member, staff) Note that deny all happens by default, this is to be explicit

28. ACL Configuration: Guest Rules Allow guest access to: Index controller pages (about page, etc) Register and login insider UserController Error controller (technicality, but good to do for later)

29. ACL Configuration: Member Rules Allow member access to: Do anything inside UserController, except delete a user Do anything with tasks Note that further security is needed to make sure members can’t mess with other people’s tasks, but this won’t happen here.

30. ACL Configuration: Staff Let staff delete users:

31. Access Control Accomplished… Well, Access Control created…

32. Point of Auth and Access Control? Fantastic, I have things that will control access to my app Where do I use them?

33. Point of Control? Could test inside each action method…

34. Point of Access Control? Works, but not ideal: Very redundant What if you want to add logic later Logging Blacklist IP of repeat offender Etc Separation of concerns: action method should only have to worry about what it does.

35. Point of Access Control? What we’d like is to: Put the Access Control logic in one place, have it run before all action methods If the user is allowed, proceed as usual If not, redirect to login (for guest) or home (for member) Almost like a “onPreAnyActionMethod” hook…

36. Detour: ZF Dispatch Process Stuff happens before and after action method Hooks exist in ZF controller architecture, various ways to plug in. Observe an event, idea similar to Javascript events Doctrine model/connection events Firefox plugins Let’s take a look at the app flow…

37. ZF Request Dispatch Process Simplified ZF Request Process Request to Response

38. Point of Access Control in ZF Request Dispatch Process preDispatch lets us make a decision before the action runs

39. preDispatch preDispatch happens before the action method is dispatched Always runs, hard-coded into controller architecture Can redirect or otherwise alter request in preDispatch 3 ways to hook into preDispatch

40. ZF – preDispatch Phase Three parts of preDispatch

41. ZF – preDispatch Options Three ways to hook into preDispatch phase: Use preDispatch method of the controller Use action helpers Use front controller plugins

42. preDispatch Option #1: Method of Controller Zend_Controller_Action has preDispatch method. Override in extending class.

43. preDispatch Option #1: Method of Controller Pros: Simple Always runs before action method Cons Can be overridden in extending class Extending class must call parent method, doesn’t happen implicitly All controllers must extend same base class

44. preDispatch Options #2 and #3:Plugins and Action Helpers Plugins and Action helpers are: Objects With preDispatch methods preDispatch methods are run prior to action method Will run no matter what controller is being invoked

45. preDispatch Options #2 and #3:Plugins and Action Helpers Similar to: Javascript event listeners Doctrine event listeners Can plugin as many or as few as you like

46. preDispatch Options #2 and #3:Plugins and Action Helpers Pros: Harder to accidentally over-ride: aren’t over-riden by sub-classes of controller base class. Run before action method of any controller Highly modular Hook into multiple events with one class Cons: Small increase in complexity: Need to know what they are Another place to look for logic

47. Plugins and Action Helpers Plugins register with Front Controller Plugins have more opportunities to hook into dispatch flow (7 hooks available) Action helpers register with a special broker Can access controller object easily in pre and post dispatch Can also provide extra functionality (help) to the controller We’ll deal with action helpers

48. Action Helpers This is an action helper…that’s it preDispatch method is called inside ZF

49. Auth Action Helper: Get the user object, if available, inject into controller

50. ACL Action Helper Grab user from controller (assume Auth helper goes first) Redirect to login if access denied (simply reset action and controller name)

51. Security Accomplished! Use Zend_Auth to verify a user is who he says he is Use Zend_Acl to verify that person can do what he’s requesting Use action helpers (or front controller plugins) to reliably hook into application flow without repeating yourself

52. While We’re on Action Helpers Register helpers with the helper broker: Zend_Controller_Action_HelperBroker::addHelper(new Zx_Controller_Action_Helper_Acl()); Need not implement pre/postDispatch Access in action methods for help with complex logic From with controller: $this->_helper->helperName (overloading) $this->getHelper($helperName) Can help keep controller classes clean Many built in, including…

53. Action Helpers: Redirector Lets you redirect user without dealing with headers

54. Action Helpers: JSON Easily send JSON response, appropriate headers sent, data encoded.

55. Action Helpers: Action Stack Stack actions to run after the current action. Can help widgetize pages: User edit page might be combination of 4 forms, rather than 1 giant form

56. Not Bad… We have: DB access up and running User system running Basic security And we can make and user action helpers But…

57. Doesn’t Look Great

58. Back to the View Would like to create a site wide look and feel Each view script should only be responsible for it’s content Almost want a template to inject view script output into

59. Site Wide Layout: Zend_Layout ZF has layout component Single view script that runs after main content is generated Can inject content into the desired location Can change layout script in different parts of site Disable if necessary (JSON/XML response, etc) Integrates with JSON action helper, other components

60. Zend_Layout: Setup Enable in application.ini Enables layout resource, sets default layout script /views/layouts/default.phtml will be layout Default specified in first line, phtml ext assumed

61. Zend_Layout: Layout File View script output injected into markup

62. Zend_Layout: Voila! Modified from http://www.456bereastreet.com/lab/developing_with_web_standards/csslayout/2-col/finished.html

63. Layout: Explained View script output is buffered and stored in response object Output stored in content “segment” by default. Output can be organized into different segments. Layout view script has access to the response segments, and injects them into the template

64. Layout: Explained Q: How does the layout script get the response segments: A: The layout view helper.

65. View Helpers View Helpers are to View Scripts what Action Helpers are to Action Methods Objects plugged into the view to separate complex logic from display logic From inside a view script, access with: $helper = $this->helperName $layoutHelper = $this->layout $urlHelper = $this->url

66. Layout View Helper Here, the layout view helper is accessed… …and it’s content property contains the content segment of the response

67. URL View Helper Forms URL based on a route Useful when doing non-standard routing

68. Action View Helper Run an action, grab the output, and place it where you want it:

69. Further Resources ZF Reference Guide http://framework.zend.com/manual/en/ Zend Casts http://www.zendcasts.com/ The Internet www.google.com

70. Questions?

71. New York City area Zend Framework Meetup http://www.meetup.com/ZendFramework-NYCmetro/ Affiliated with http://www.nyphp.org/ Thanks for attending “Your First Zend Framework Project, Part Two” presented on March 22, 2011 by Isaac Foster http://www.linkedin.com/in/isaaczfosterisaac.z.foster@gmail.com Alan Seiden http://www.alanseiden.comalan@alanseiden.comTwitter: @alanseiden Sign up to hear about all our ZF meetups at http://www.meetup.com/ZendFramework-NYCmetro/