Search

The topic of access control has received a new lease of life in recent years as the need for assurance that the correct access control policy is in place is seen by many as crucial to providing assurance to individuals that their data is being treated appropriately. This trend is likely to continue with the increase in popularity of social networking sites and shifts to `cloud΄-like commercial services: in both contexts, a clear statement of ˵who can do what″ to one΄s data is key in engendering trust. While approaches such as role-based access control (RBAC) provide a degree of abstraction, therefore increasing manageability and accessibility, policy languages such as the XML-based XACML provide greater degrees of expressibility–and, as a result, increased complexity. In this paper we explore how the mutual benefits of both RBAC and XACML, and Alloy and Z, may be used to best effect. RBAC is used as an accessible conceptual model; XACML is used as a language of implementation. Our concern is to facilitate the construction and reuse of role-based policies, which may subsequently be deployed in terms of XACML. We wish to provide assurance that these representations and transformations are, in some sense, correct. To this end, we consider formal models of both RBAC and XACML in terms of Z. We also describe how we have taken initial steps in utilising the Alloy Analyzer tool to provide a level of assurance that the two representations are consistent. [ABSTRACT FROM AUTHOR]

As an increasing amount of healthcare-related data is captured in both clinical and research contexts, the drive to provide appropriate access to such data becomes stronger. The very nature of such data means that simplistic approaches to authorisation–be they coarse-grained or role-based–are insufficient: the needs of the domain give rise to requirements for authorisation models capable of capturing fine-grained, expressive access control policies. We describe the development of a framework for the secure sharing and aggregation of healthcare-related data, called sif (for service-oriented interoperability framework). In particular, we concentrate on the access control aspects of the system and describe its utilisation of XACML in this respect. [ABSTRACT FROM AUTHOR]

The Spry gallery that you built in the previous chapter has two important shortcomings. First, the page's content is generated entirely inside the browser using JavaScript, leaving nothing for a search engine to index and failing miserably in an older browser or if JavaScript is disabled. Second, although the content is generated dynamically, the XML sources are static. In the case of a photo gallery, this might not be a major drawback, but one of the main reasons for creating dynamic web pages is to exploit the ability to update content on the fly without the need to build everything from scratch again. Rather than creating a new XML document every time a new photo is added or deleted, it's more convenient to add or delete the details from a database and generate the XML dynamically. This has the added advantage that you can use the database content for other purposes, greatly increasing your efficiency. [ABSTRACT FROM AUTHOR]

The ability to manipulate XML data without the need to refresh the web page lies at the very heart of Ajax. It's also the prime motivation behind Adobe's decision to develop the Spry framework. In theory, it's the most exciting development in Dreamweaver CS3. The reality leaves much to be desired, partly because of the accessibility problems that I outlined in Chapter 2, but also because Spry is still work in progress. The original release of Dreamweaver CS3 incorporated Spry 1.4. Only a month later Spry 1.5 was made available on Adobe Labs (http://labs.adobe.com/technologies/spry/), raising expectations of an update for Dreamweaver. It took a further month before Adobe announced that an extension to update Dreamweaver would be made available for the "production release" of Spry during summer 2007. Details were still hazy at the time this book went to press, but it's anticipated that there may be three or four releases of Spry before the next version of Dreamweaver. At the time of this writing, it had not been decided whether to release extensions on a regular basis to allow Dreamweaver to keep pace with new features in Spry. [ABSTRACT FROM AUTHOR]

Extensible Markup Language (XML) is probably one of the most hyped and least understood aspects of web development. XML has the simple objective of storing data in a format that both humans and computers can easily understand. It's not a database, nor is it a programming language. It's a highly structured way of presenting data. Because it uses tags like HTML and XHTML, XML looks very familiar to web developers. However, there is no master list of tags or attributes, and although XML frequently contains data intended for display on the Web, it provides no way of displaying it. [ABSTRACT FROM AUTHOR]

We don't store information in a database simply for the fun of it. The idea of a database is to make it easy to find the precise information you want, when you want, and without the need to reorganize it constantly. To do this successfully, you need a good knowledge of SQL. It's a vast subject, so I'll only be able to scratch the surface by showing you some basic search techniques. [ABSTRACT FROM AUTHOR]

In Chapter 14, I explained that an important principle of working with a relational database was the need to break larger units, such as addresses or names, into their component elements and store them in separate columns. Another equally important principle is to get rid of columns that contain repetitive data and move them to a separate table. As long as each record has a primary key to identify it, records in separate tables can be linked by storing the primary key from one table as a reference in the other. This is known as creating a foreign key. [ABSTRACT FROM AUTHOR]

In the last chapter, you learned how to insert information into a database and retrieve it. Once you have created a database record, you need a way to update it or delete it when it's no longer required. The principles behind updating and deleting are very similar to retrieving and displaying records. To update a record, you need to display its existing details in a form ready for editing, and to delete a record, you display sufficient information to confirm that you want to consign it to cyber oblivion. [ABSTRACT FROM AUTHOR]

Unlike Access or FileMaker Pro, MySQL doesn't come with predesigned forms. Instead, you build and design everything yourself. While this presents a challenge to the first-time user, MySQL isn't difficult to use, and Dreamweaver takes a lot of the hard work out of integrating MySQL with your website. [ABSTRACT FROM AUTHOR]

Dynamic websites take on a whole new meaning in combination with a database. Drawing content from a database allows you to present material in ways that would be impractical—if not impossible—with a static website. Examples that spring to mind are online stores, such as http://Amazon.com; news sites, such as the International Herald Tribune (http://www.iht.com); and the big search engines, including Google and Yahoo! Database technology allows these websites to present thousands, sometimes millions, of unique pages with remarkably little underlying code. Even if your ambitions are nowhere near as grandiose, a database can increase your website's richness of content with relatively little effort. [ABSTRACT FROM AUTHOR]

To give a unified look to a website, most pages have common elements, such as a header, navigation menu, and footer. Nobody likes repeating work just for the sake of it, so the ability to build page templates has long been one of Dreamweaver's most popular features. All common features can be defined and locked, but Dreamweaver propagates to all child pages any changes that you make to the master template. The great disadvantage is that every time you make a change all the affected pages must be uploaded again to your remote server. On a large site, this can be a major undertaking. [ABSTRACT FROM AUTHOR]

In Chapter 9, I showed you how to build a feedback form and validate the input on the client side with Spry validation widgets. In this chapter, we'll take the process to its next stage by validating the data on the server side with PHP. If the data is OK, we'll send the contents by email and display an acknowledgement message. If there's a problem with any of the data, we'll redisplay it in the form with messages prompting the user to correct any errors or omissions. Figure 11-1 shows the flow of events. [ABSTRACT FROM AUTHOR]

This chapter is a cross between a crash course in PHP and a handy reference. It's aimed at readers who are completely new to PHP or who may have dabbled without really getting to grips with the language. The intention is not to teach you all there is to know but to arm you with sufficient knowledge to dig into Code view to customize Dreamweaver code with confidence. Dreamweaver's automatic code generation does a lot of the hard work for you, but you need to tweak the code to get the best out of it, and when it comes to sending an email from an online form, you have to do everything yourself. [ABSTRACT FROM AUTHOR]

Online forms are the gateway to the server, and lie at the very heart of working with PHP, the focus of most of the remaining chapters. You use forms for logging into restricted pages, registering new users, placing orders with online stores, entering and updating information in a database, and sending feedback by email. But gateways need protection. [ABSTRACT FROM AUTHOR]

A common dilemma with website design is too little space to display all the content that needs to be on a particular page. Spry widgets to the rescue ... In common with other Ajax frameworks, Spry makes it easy to build components— such as accordions and tabbed and collapsible panels—that slot into a web page and give it a much more dynamic feel. The Spry Tabbed Panels (see Figure 8-1) and Spry Accordion (see Figure 8-18) are a series of interlinked panels, in which just one panel is open at a time. Spry Collapsible Panels work independently, so they can be opened and closed in any combination. [ABSTRACT FROM AUTHOR]

Efficient and attractive navigation is an important element in every website. The Spry menu bar is one of eight Spry widgets new to Dreamweaver CS3 (the others are described in the next two chapters). Its aim is create a flexible menu with flyout submenus that remains accessible even if JavaScript is turned off. In essence, it's an unordered list with optional nested lists for submenus. Styling is done with CSS, and the submenu flyouts are controlled by a combination of CSS and JavaScript. It comes in two versions: horizontal and vertical. Figure 7-1 shows what the horizontal version of the Spry menu bar looks like when integrated into the page built in the last chapter. [ABSTRACT FROM AUTHOR]

Much of the book so far has been devoted to the mechanics of setting up your work environment and getting to know the tools that Dreamweaver provides. From this point onward, the approach will be more "hands on," showing you how to build standards-compliant sites with Dreamweaver. [ABSTRACT FROM AUTHOR]

Judging by the runaway success of books such as CSS Mastery by Andy Budd with Simon Collison, and Cameron Moll (friends of ED, ISBN-13: 978-1-59059-614-2), web designers have finally got the message that Cascading Style Sheets (CSS) are the way to design a website. Getting the message is the easy part, but many designers rapidly find their initial enthusiasm takes a severe dent when they run into the reality of creating a CSS-driven site. Creating a style rule is simple enough, and most CSS properties have intuitive names. The difficulty lies in the infinite number of ways in which style rules can be combined. And that's what makes it so powerful and worthwhile. You need only visit the CSS Zen Garden at http://www.csszengarden.com to see why—the underlying XHTML of every page is identical; what makes each one so different is the CSS. [ABSTRACT FROM AUTHOR]

If you're a regular Dreamweaver user, I don't need to tell you the importance of site definition; it's how Dreamweaver organizes your web files and makes sure that links point to the right place. If you're in a hurry, and working with static web files, Dreamweaver will let you create a quick page without saving it within a defined site. That won't work with PHP pages. Dreamweaver uses the site definition to determine which tools to make available to you. Unless you choose the correct server model, all the PHP server behaviors will be inaccessible, and you won't be able to test your files. [ABSTRACT FROM AUTHOR]

Although Dreamweaver lets you use a remote server—such as a hosting company—to test PHP pages, it's usually more efficient to set up a testing environment on your local computer. All the necessary software can be downloaded free of charge from the Internet, and it's not difficult to set up. Don't worry about the length of this chapter. It contains separate instructions for Windows and Mac OS X, and the Windows section covers both XP and Vista, as well as Apache and IIS. There are also troubleshooting hints in the unfortunate event that anything goes wrong. [ABSTRACT FROM AUTHOR]

In the last chapter, I discussed many of the new and improved features in Dreamweaver CS3, but the one with the real "wow factor" is Spry, Adobe's implementation of Ajax. Although Ajax started out as an acronym for Asynchronous JavaScript + XML, it's taken on a broader meaning. In simple terms, it's a combination of existing technologies that allow you to change the content of a web page without the need to reload it in a browser, and rival implementations have mushroomed at a breathtaking pace. Ajax is not without problems, particularly with regard to accessibility and search engine optimization, so in this chapter, I'll explain what Ajax is, what its pluses and minuses are, and how Dreamweaver has implemented the Adobe version called Spry. I'll also be discussing PHP, the most popular server-side language, which—among other things—activates online forms to send email, communicate with a database, and make websites searchable. [ABSTRACT FROM AUTHOR]

After 8, comes ... not 9, but CS3. In the confusing world of marketing, Dreamweaver versions have gone from straightforward numbers to a couple of meaningless letters (MX), to MX 2004 (which didn't reflect the year of release accurately), and back to numbers again. So why CS3? And does it make any sense? [ABSTRACT FROM AUTHOR]

OGSA-DAI is a reference implementation of the OGSA Data Access and Integration services that facilitates homogeneous access to a wide range of databases, with this access being independent of the underlying database schemas and database management systems. In this paper we propose a secure wrapper for OGSA-DAI to allow an existing OGSA-DAI installation to be secured against inappropriate actions. The wrapper utilises XACML. [ABSTRACT FROM AUTHOR]

The utilisation of real medical data in research projects is becoming evermore widespread, and a clear duty of care towards such data is mandatory. To this end, anonymisation is essential. It is well understood that a conflict between functionality and confidentiality exists within this context: while patients' confidentiality must be preserved, restricting access can reduce the value of the data that is available to researchers. As such, limiting access so that confidentiality is preserved while still ensuring a high degree of functionality should be a key aim of every designer of medical research databases. In this paper, we outline an approach developed within the e-DiaMoND project that combines anonymisation and query modification to manage this conflict. [ABSTRACT FROM AUTHOR]