Peter Mesotten 8 Years Ago Nice post.A cleaner solution might be to write a servlet filter or a ServicePreAction hook that listens for the default portrait URL (/image/user_male_portrait?img_id=23360&img_id_token=...&t=...), use the img_id parameter to find out which user it belongs to and use his/her emailadress for the translation to a Gravatar url? I think this kind of solution would be less intrusive. Please sign in to reply. Reply as... Cancel David H Nebinger Peter Mesotten 8 Years Ago If you can return the right image link to the browser, then the browser will issue the request.If you're intercepting as a servlet filter then you have to proxy the call to the external service and feed the binary data back.Some enterprises do not like having their DMZ establish outbound HTTP connections and question that kind of thing as a security vulnerability.There's also a question of scalability and whether you really want your server handling these things at all if they can be avoided.If these issues are not concerns, you're absolutely right that the servlet filter or ServicePreAction would be a less-intrusive path.The wrapper definitely has holes, so combining it w/ the servlet filter or ServicePreAction could be a simpler way to patch all of the holes. Rather than dealing with all DQ and custom query invocation, you fall back to allowing the servlet filter to be the "catch all". Since it is the path less often taken scalability is not an issue and, as a one-off, it may be easier justifying proxying the external web call... Please sign in to reply. Reply as... Cancel Ram Kumar David H Nebinger 7 Years Ago Nice Post Please sign in to reply. Reply as... Cancel
David H Nebinger Peter Mesotten 8 Years Ago If you can return the right image link to the browser, then the browser will issue the request.If you're intercepting as a servlet filter then you have to proxy the call to the external service and feed the binary data back.Some enterprises do not like having their DMZ establish outbound HTTP connections and question that kind of thing as a security vulnerability.There's also a question of scalability and whether you really want your server handling these things at all if they can be avoided.If these issues are not concerns, you're absolutely right that the servlet filter or ServicePreAction would be a less-intrusive path.The wrapper definitely has holes, so combining it w/ the servlet filter or ServicePreAction could be a simpler way to patch all of the holes. Rather than dealing with all DQ and custom query invocation, you fall back to allowing the servlet filter to be the "catch all". Since it is the path less often taken scalability is not an issue and, as a one-off, it may be easier justifying proxying the external web call... Please sign in to reply. Reply as... Cancel Ram Kumar David H Nebinger 7 Years Ago Nice Post Please sign in to reply. Reply as... Cancel