- changed status to open
Refrain from using the admin logic for picture handling
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)
-
reporter -
-
assigned issue to
-
assigned issue to
-
I would vote against b2 - the Gravatar link is nothing which should be handled on the database layer. b1 goes into the right direction.
-
- changed version to 2.0.44
-
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".
-
- edited description
-
- edited description
-
- edited description
-
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.
-
- changed version to 2.0.45
-
- changed version to 2.0.47
-
-
assigned issue to
-
assigned issue to
-
-
- changed milestone to 3.0.0
-
- changed milestone to 3.0.1
-
- changed milestone to 3.0.2
-
- changed milestone to 3.2
-
- removed milestone
-
- changed milestone to 3.8.0
-
- removed responsible
- removed milestone
- Log in to comment