Hi,
I think I found my gallery of choice. The modularity of g2 is what I was looking
for. So, here's a draft from me for my first g2 module called "Tickets".
Preambel
--------
As a "cam guy" I've a lot of party photos of my friends and me. But because
I'm concerned about privacy, I don't want these pictures to be available for
the public. But neither do I want to exclude someone, who attended to a
party, from viewing the photos by requiring registering as a user. Of course,
if so, it's more convenient. But often they're new people and just don't know
me enough to register to my site or for other reasons. So I came up with the
following idea.
Idea
----
The main idea is to grand one or more persons access to some gallery item
without having and requiring an user account.
Album Owner Details
-------------------
The following steps need to be taken in order to generate a ticket:
- navigate to an item (e.g. album) that you want a ticket for
- the "Make ticket" link brings you to new page for settings for this ticket
- setting are:
- ticket name / description
- time to expire (e.g. 30 days, until 17th June 2006, ..)
- permissions for this ticket, as in the user permission settings
- (optionally) enter email adresses to send the ticket to in the recepient box
- (optionally) edit the default ticket message within the message box
- click the create button to create and eventually send the ticket
The site administration page shows a settings item named "Tickets" where the
generated tickets can be deleted, reactivated, resend, change
permissions or expand the expire date. Expired tickets are kept for
reactivation until they are deleted. The "Delete expired tickets" button
deletes all expired tickets.
User Details
------------
As a user you get a simple URL to visit, in most cases it's within an email. By
visiting the link you're getting to the item and have the permissions given to
the ticket.
Technical Implementation
------------------------
A ticket itself has a 32 byte random value for identification (not as primary
key id). Of course this doesn't prevent someone from brute forcing all
possible combination, but that is neglected. The resulting URL looks like this:
http://mygallery.com/ticket.php?J12J389KJ1908J43029JLJ90AS01J890
I can think of two possible ways to integrate this into the database. A table
for the tickets with the options is used in both cases.
In case one two additional tables are created as the AccessMap
AccessSubscriberMap. Named TicketAccessMap and TicketSubscriberMap.
The former has a ticketId field instead of the userId and groupId fields.
Case two is IMHO more elegent. Adding a new column ticketId to the
AccessMap is the least afford on the database side. A problem might be the
unique key wich currently consists of accesslistId, userId and groupId.
Maybe it's safe to expand the unique key with ticketId.
--- END ---
Thanks for the reading. Any comments are welcome. Whether it is on the
design or the technical implementation. I would like to here opinions and
suggestions before I'm going to implementing it.
Posted: Thu, 2005-05-05 11:08
Posts: 7994
So in this case, a ticket is kind of like a disposable ACL, right? You take an image and render it invisible to people in the "Everybody" group, then present a UI where the user can create a new ACL which grants view privileges. Users who come to the gallery can get that ACL into their session by entering a password (or following a url), and then have that ACL until their session (or the ticket) expires.
That sounds like a good solution to me. We've discussed something like this in the past, and it's a feature that we'd like to have. I don't think that we'll need to make any modifications to the existing Access tables, we just need to keep track of which ACLs are transitory so that we avoid compressing them when we do ACL compression. If you want to work on this, we'll be happy to provide guidance.