Peter Mesotten 8年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Peter Mesotten 8年 前 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... 投票するためにはログインが必要です。 次として送信する: キャンセル Ram Kumar David H Nebinger 7年 前 Nice Post 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Peter Mesotten 8年 前 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... 投票するためにはログインが必要です。 次として送信する: キャンセル Ram Kumar David H Nebinger 7年 前 Nice Post 投票するためにはログインが必要です。 次として送信する: キャンセル