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

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."Using jQuery within the KU Template"

For Sites Google Analytics –Enable Google Analytics for the site: –If applicable, specify your site-specific Google analytics code: Verify the site title, keywords, and descriptions

For Sites CSS –IE stylesheets using link tags, See slide #10 from our April 2nd, 2009 presentation.See slide #10 from our April 2nd, 2009 presentation. –Include common2009.css 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, 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)

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

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.microformats Verify that the page is using the 2009 version of the footer.

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

Google Accounts Determining the Google account –Departmental account Sign up – –Confirmation: Example Subject: Google Verification Welcome to Google Accounts. To activate your account and verify your address, please click the following link: M2F5JqXkwEQ7YuMtujc6p4W&hl=en

Departmental Codes Contact: Web Services Google Analytics KU Departmental Code: example: UA

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 – Accessing Google Analytics –

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

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;

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

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.

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');

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.

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');

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()

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() , '/'); } session_destroy();

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

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