Site and Page Checklists

1. Site and Page Checklists Consistency? What’s that?!

2. For Sites • KU Template • Use current KU template (where feasible) • Turn off or remove kuoldcompatible variable • The new KU template includes jQuery by default. Verify that the site is not including a second local copy. • Note: Also remember that the new KU specific installation of jQuery uses the syntax $kuj() instead of jQuery's normal $() for selectors. See: "Using jQuery within the KU Template" for more information.

3. For Sites • Google Analytics • Enable Google Analytics for the site:<!--#set var="googleanalytics" value="1" --> • If applicable, specify your site-specific Google analytics code:<!--#set var="googlecode" value="CODE" --> • Verify the site title, keywords, and descriptions

4. For Sites • CSS • IE stylesheets using link tags, not @import. See slide #10 from our April 2nd, 2009 presentation. • Include common2009.css using @import. See the differences between common.css and common2009.css before you do this. Some of the CSS classes have changed! (differences coming soon). • If your site includes forms, use @import to include the forms2009.css file and forms2009_ie6.css / forms2009_ie7.css files. (The _ie# files should be included using the link method mentioned above. See the differences between forms.css and forms2009.css. (Coming soon)

5. For Pages • Verify that all appropriate SSI variables are set • Page Title • Page Keywords • Page Description • Breadcrumbs • etc…

6. For Pages • Check the site for valid HTML • Verify that no inline CSS is being used • Verify that no inline JS is being used • Use semantic markup • Use microformats where applicable. • Verify that the page is using the 2009 version of the footer.

7. Google Analytics Acquiring a Google account, requesting a departmental code, and adding to your site pages

8. Google Accounts • Determining the Google account • Departmental email account • Sign up • https://www.google.com/accounts/ManageAccount • Confirmation: Example email: Subject: Google Email Verification Welcome to Google Accounts. To activate your account and verify your email address, please click the following link: http://www.google.com/accounts/VE?service=analytics&c=CJbOgM2F5JqXkwEQ7YuMtujc6p4W&hl=en

9. Departmental Codes • Contact: Web Services • webservices@mail.ku.edu • Google Analytics KU Departmental Code: example: UA-876256-32

10. Adding Google Analytics to Your Site KU Template Configuration Variables • The newest version of the KU Template must be implemented on the site • Example: ~myssi\myheader.shtml • <!--#set var="googleanalytics" value="1" --> • <!--#set var="googlecode" value=”your dept code" --> • Accessing Google Analytics • http://www.google.com/analytics/

11. PHP Session Management What they are, why you should use them, and how to do so securely

12. What are Sessions? • Sessions are like server-side cookies • The data live in text files on the server • Allows you to store more data than you’ll likely ever need • The server links the user to their session data using a session ID in the URL (bad!) or in a cookie • Data is accessible via $_SESSION superglobal array • $x = $_SESSION['x']; $_SESSION['y'] = $y;

13. Why use them? • FAR more secure than cookies because the data doesn’t live on the client machine • Can store much more than a simple cookie • Easier to test with since you can see the session data files on the server

14. How to use them • session_start(); //that’s it, you’re done • We can do better than that though. • Caveat: • This command sends a cookie. Cookies are sent via HTTP headers. Therefore… • You need to use this command BEFORE any page content is sent to the browser • This is the most common mistake people make when beginning to use sessions. If you need to, use output buffering.

15. How to use them securely • All must be done before calling session_start() • Don’t send the session ID as part of the URL • This makes session hijacking MUCH harder • This is the most important setting you can change • ini_set('session.use_only_cookies', '1'); • Use SHA-1 instead of md5 for session IDs • md5 has been cracked multiple times • SHA-1 results in longer session IDs (more secure) • This is not encrypting the session, just generating IDs • ini_set('session.hash_function', '1');

16. How to use them securely (cont.) • Session cookie settings are changed by session_set_cookie_params(), which runs 5 separate ini_set calls. Think setcookie() • Expiration time • Path • Domain • Secure (only send the cookie over HTTPS) • HTTP only • If true, the session cookie is not accessible via JavaScript. Big gains against XSS but not supported by all browsers.

17. How to use them securely (cont.) • Here’s what we use: • session_set_cookie_params('7200', '', '', true, true); //2 hours, default path, default domain, https only, no JS access • 2 hours is arbitrary, but that’s how long a Shibboleth session lasts • Set a session name (avoids confusion and/or collisions). Don’t forget this value. • session_name('name goes here');

18. How to use them securely (cont.) • Set a more secure save path • session_save_path('path/goes/here'); • Default path is Apache’s /tmp directory, which is globally readable • Others on the server can snoop through your session files…they are plain text • Create a directory for sessions in your web account, above public_html (like /home/account/tmp or /home/account/sessions) and use that instead • Remember to call these before session_start()

19. How to end a session • We blatantly stole this from the PHP manual and we recommend you do the same. $_SESSION = array(); if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time() - 42000, '/'); } session_destroy();

20. We’ve done the work for you • All of this code has been rolled up into a static class you can use. • Example (pretend this is the last page): require_once '/home/ssts_lib/lib/SPEAR/SessionLocal.php'; SessionLocal::start('session name', 'save/path'); ob_start(); //don’t send any page content yet page page page… SessionLocal::kill(); //kill the current session ob_end_flush(); //send the page content

21. Other best practices for sessions • Whenever authentication changes (sign in, sign out, get more/less rights, etc…) make a new session ID • session_regenerate_id(); //keeps the data but changes the ID • Don’t use a session to store authentication information (like $_SESSION['allowed']=1;) • If feasible, restrict sessions to a single IP • Might not work for users behind a proxy