Refrain from using the admin logic for picture handling

Issue #1914 open
Stephan Doerfel created an issue

The pictureController currently relies on an admin logic to retrieve a users email Adresss.

The injected logic in bibsonomy2-actions-servlet.xml is in Fact the admin Logic. The reason for using the admin Logic is that for gravatar we need the email-address (or more precisely its hash) of the reqeusted user. Since the mail address is private, only admins and the respective owner may see it.

Using the admin logic here is unfortunate.

  • a) when the admin logic is used this should be marked clearly by naming it admin logic
  • b) the use of the admin logic can be avoided by sorting out the problemat hand in the database module.
    • b1) We could make the hash of a users email a public field and always have it in the user object. Thus we can construct the link by using this public field
    • b2) We could store the gravatar link directly into the user object. Since it includes the hash, the privacy concerns are the same as for b1). However, we only need the hash for those users who use gravatar.

For both versions we will have to load the users email from the database (and delete it after we computed its hash in cases where the email should not be visible). This would be best solved by some preprocessor in iBatis that creates the hash or the link directy after the object has been constructed from the database rows and before it is handled in any manager (take a look at typeHandlers in iBatis).

Comments (20)

  1. Robert Jäschke

    I would vote against b2 - the Gravatar link is nothing which should be handled on the database layer. b1 goes into the right direction.

  2. Former user Account Deleted

    B1 sounds quite comfortable – however, this solution limits us to MD5 hash. Indeed, Gravatar requires md5. But, as far as other services shall be possible to include in future, and the PictureHandler classes are heading that, future services may not.

    Unfortunately, by now my only alternative would be to pass the desired hash algorithm to the database manager; I'm afraid this might be a bit "oversized".

  3. Robert Jäschke

    Yes, it is. I would suggest to stick for MD5 now. If we really want/need to add another service, we can see how to solve the issue.

  4. Log in to comment