The document is a tutorial about designing and implementing a wiki database and application using Howdah. It discusses designing the database and application, defining API contracts, adding user authentication and authorization features including administrative users, and adding a new feature to the user profile page to list pages edited by each user. Security, permissions, and data confidentiality are important considerations throughout the design process.

1. HOWDAH
A tutorial
Tuesday, October 20, 2009

2. Why?
Howdah is for people who really “get” databases
Howdah treats your database as code. Procedures,
and hand-written SQL.
Would you automate python generation? Then why
SQL?
Just because it’s not code you’re comfortable with,
doesn’t make it any less code.
2
Tuesday, October 20, 2009

3. What shall we build?
Today, we’ll be talking about designing and
implementing a Wiki.
3
Tuesday, October 20, 2009

4. Why a Wiki?
Canonical example
Simple enough to define in an afternoon
Complex enough to require in-depth exploration
4
Tuesday, October 20, 2009

5. Why a Wiki?
Public and Private permissions/users
Read/write collaborative model
5
Tuesday, October 20, 2009

6. Design vs. Code
Speaking more on Design than on Code
Why is more important than How.
How is still important
6
Tuesday, October 20, 2009

7. STEP 1:
DESIGN
7
Tuesday, October 20, 2009

8. Database
What do we need?
8
Tuesday, October 20, 2009

9. Application
What do we need?
9
Tuesday, October 20, 2009

10. Application
What do we need?
Anything else? Did we miss anything?
10
Tuesday, October 20, 2009

11. STEP 2:
REVISIT
11
Tuesday, October 20, 2009

12. Database
Based on our Application design, what expansions do
we need?
12
Tuesday, October 20, 2009

13. Database
Based on our Application design, what expansions do
we need?
Why do we need them?
13
Tuesday, October 20, 2009

14. Application
With the new DB features, what changes?
14
Tuesday, October 20, 2009

15. Application
With the new DB features, what changes?
What new ideas are evident?
15
Tuesday, October 20, 2009

16. Application
With the new DB features, what changes?
What new ideas are evident?
Do the changes make things easier?
16
Tuesday, October 20, 2009

17. STEP 3:
API CONTRACTS
17
Tuesday, October 20, 2009

18. Database
Defining our API
What stored procedures do we need?
18
Tuesday, October 20, 2009

19. Database
Defining our API
What stored procedures do we need?
What should they do?
19
Tuesday, October 20, 2009

20. Database
Defining our API
What exceptions do we need?
20
Tuesday, October 20, 2009

21. Database
Defining our API
What exceptions do we need?
Null data
Bad data
No such record
21
Tuesday, October 20, 2009

22. Application
Defining our API
What models do we need?
22
Tuesday, October 20, 2009

23. Application
Defining our API
What exceptions do we need?
23
Tuesday, October 20, 2009

24. Application
Defining our API
What exceptions do we need?
What do DB exceptions become?
What HTTP responses should the exceptions
raise?
24
Tuesday, October 20, 2009

25. Application
Defining our API
What views do we need?
25
Tuesday, October 20, 2009

26. Application
Defining our API
What views do we need?
What views are read-only? Read-write? Write-only?
26
Tuesday, October 20, 2009

27. STEP 4:
FIRST EXPANSION
USERS
27
Tuesday, October 20, 2009

28. Database
Users
User system!
28
Tuesday, October 20, 2009

29. Database
Users
User system!
VerticallyChallenged for users
29
Tuesday, October 20, 2009

30. Database
Users
User system!
VerticallyChallenged for users
How to set up VC
30
Tuesday, October 20, 2009

31. Database
Users
Stored Procedures - How do we adapt them?
How does this affect our API contract?
31
Tuesday, October 20, 2009

32. Application
Users
Using @needs to define permissions
How should views be protected?
32
Tuesday, October 20, 2009

33. Application
Users
Using @needs to define permissions
How should views be protected?
Should anonymous users have write permission?
33
Tuesday, October 20, 2009

34. Application
Users
Permissions violations
What should no user return?
What should a bad user return?
What should insufficient permissions return?
34
Tuesday, October 20, 2009

35. Application
Users
Why - Are there better mechanisms?
35
Tuesday, October 20, 2009

36. STEP 5:
ADMINISTRATIVE
USERS
36
Tuesday, October 20, 2009

37. Database
Administrators
What delineates an admin?
What special things can an admin do?
Should admins be otherwise normal users?
37
Tuesday, October 20, 2009

38. Database
Administrators
Root-level permissions:
Should the database superuser ever be allowed to log
in from the web app?
38
Tuesday, October 20, 2009

39. Database
Administrators
Root-level permissions:
Should the database superuser ever be allowed to log
in from the web app?
Why?
39
Tuesday, October 20, 2009

40. Application
Administrators
What delineates an Admin?
40
Tuesday, October 20, 2009

41. Application
Administrators
Design
Are there special admin-only views?
How do we protect admin privileges?
Are there user-specific views? Do admins have
permission to access those?
Is anything changed by the DB layer?
41
Tuesday, October 20, 2009

42. Application
Administrators
Should administrators be able to view everything?
42
Tuesday, October 20, 2009

43. Application
Administrators
Should administrators be able to view everything?
What about privileged information?
HIPAA, lawyer confidentiality
43
Tuesday, October 20, 2009

44. Application
Administrators
Should administrators be able to view everything?
What about privileged information?
HIPAA, lawyer confidentiality
How can we protect privileged information like this?
Can we ever guarantee protection? How?
44
Tuesday, October 20, 2009

45. STEP 6:
A NEW FEATURE
45
Tuesday, October 20, 2009

46. A New Feature
Let’s add a user profile page
Specifically list the pages that a user has edited
46
Tuesday, October 20, 2009

47. Database
A New Feature
Design first!
47
Tuesday, October 20, 2009

48. Database
A New Feature
Design first!
Do we need new stored procedures?
What are they?
Who has access to them?
Does this require write access?
48
Tuesday, October 20, 2009

49. Application
A New Feature
What does the app need to support this?
49
Tuesday, October 20, 2009

50. Application
A New Feature
What does the app need to support this?
What views do we need?
50
Tuesday, October 20, 2009

51. Application
A New Feature
What does the app need to support this?
What views do we need?
Who has access to the views?
Logged-in users only?
51
Tuesday, October 20, 2009

52. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
52
Tuesday, October 20, 2009

53. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
Do we list entries that a user may not have read
access to?
53
Tuesday, October 20, 2009

54. Application
A New Feature
What about security and data confidentiality?
What security issues could be present?
Do we list entries that a user may not have read
access to?
Should we list nothing, instead?
Why do it like this? Are there better solutions?
54
Tuesday, October 20, 2009