Prior to release 1 Sprint 3, access control is on libraries and images inherit rights from their parent library. For display purpose, the application generates thumbnail (100x100), medium (500x500) and large (800x800) images for the master images the customer uploads. Those images are not access controlled. If you have the URL to those images, you can view them. This desicion was made mainly for performance. It is very inefficient to serve numerous images via SSL.

However, we are concerned that it is not appropriate to have no access control on those images. We will run into privacy and copyright issues. This concern becomes greater as we start to design our public domain. For example, user A puts pictures into her personal library and she gives her friend user B read access to that library. User B put some of user A's pictures in her album and shares that album with User C. Now user C can see user A's pictures without her consent or even knowledge. User C can then drag User A's images from User B's album into her own album and share it with user D. We feel that since User A only explicitly shares pictures with User B, user C and User D should not be allowed to see User A's pictures without her consent.

In release 1 Sprint 3, we changed our design to have thumbnail/medium/large inherit the master image's permissions. As a result, if User A doesn't explicitly give User C permission over her images, when User C is viewing User B's album, she will not be able to see any of User A's pictures (she will see thumbnails "NOT AUTHORIZED TO VIEW THIS ITEM").

Problems:

1. Performance. We are concerned about the performance of serving thumbnails over SSL. During our initial test, the performance seems comparable to the old design. However, we are not sure how the system will perform under large load.

2. Caching: ssl caching is a little different from regular http caching. IE7 will automatically cache SSL content, but Firefox will not. In our code, we enabled caching for thumbnails and set the caching period to 3 days. Still Firefox will only cache the ssl content in its memory cache which means once the browser is closed, the cache is gone. The next time Firefox starts, the user will have to re-fetch all the thumbnails from the server.

If the client is concerned about performance, he/she can change the Firefox behavior by turning the ssl disl caching on. Type "about:config" in Firefox's address bar. Filter by "cache", and set the property"browser.cache.disk_cache_ssl" to "true".

The thumbnails typically don't change so it is very suitable for long time caching to disk. However, the permissions do change. For example, since User C doesn't have permission to view User A's pictures, she will get that ""NOT AUTHORIZED TO VIEW THIS ITEM" thumbnail. So she asks User A for permission and gets it. However, since the thumbnails are cache, she will not see the change right away. If it is cache in memory, she can close and restart Firefox and see the changes. However, if the cache is on disk, she will have to either clear the cache or wait for 3 days until the cache expires.

  • No labels