Scripts run as least privileged user necessary?
I'm running into a strange problem. I have a situation in which I want a script to treat Managers differently than other users. But I'm finding that whether or not I'm logged in as a manager or not the script only considers the user to be 'Anonymous User' as long as 'Anonymous' has View privilege for the script. If I change the Security permissions so that only 'Authenticated' can View the script then the user is properly identified. Is this expected behaviour? This is what I'm seeing on 2.6.1. As a test create a script with return _.SecurityGetUser() be sure to bind '_' to Namespace. Set that script so that the View privilege is allowed for 'Anonymous'. Stay logged in and run the script. Then change it so only 'Authenticated' as the View privilege, run it again. The behavior changes based on the permissions. Ken Causey
Ken Causey wrote:
I'm running into a strange problem. I have a situation in which I want a script to treat Managers differently than other users. But I'm finding that whether or not I'm logged in as a manager or not the script only considers the user to be 'Anonymous User' as long as 'Anonymous' has View privilege for the script.
This is a FAQ and is related to how HTTP works. Requests are (generally) first sent without authorization credentials, if the response is 401 then the user agent will resend the request with creds (after obtaining them from the user if necessary). -- Jamie
Ken Causey wrote:
I'm running into a strange problem. I have a situation in which I want a script to treat Managers differently than other users. But I'm finding that whether or not I'm logged in as a manager or not the script only considers the user to be 'Anonymous User' as long as 'Anonymous' has View privilege for the script. If I change the Security permissions so that only 'Authenticated' can View the script then the user is properly identified. Is this expected behaviour? This is what I'm seeing on 2.6.1.
What are you trying to do with your script? There may be a better way to tackle it... cheers, Chris
On Wed, 2003-09-03 at 07:30, Chris Withers wrote:
Ken Causey wrote:
I'm running into a strange problem. I have a situation in which I want a script to treat Managers differently than other users. But I'm finding that whether or not I'm logged in as a manager or not the script only considers the user to be 'Anonymous User' as long as 'Anonymous' has View privilege for the script. If I change the Security permissions so that only 'Authenticated' can View the script then the user is properly identified. Is this expected behaviour? This is what I'm seeing on 2.6.1.
What are you trying to do with your script? There may be a better way to tackle it...
It is a precondition script whose goal is to try to prevent access to an image unless you are viewing it embedded within a page of my site. The closest I've been able to come to this goal is to add a value to the session within the page and check in the precondition script for the image that the value is defined. Although not ideal this works sufficiently. Where I'm running into the problem I described above is that I wanted to exempt managers from the check for the session variable. The obvious way to do that seemed to be to check the role of the user. I welcome any alternatives you can suggest. Thanks, Ken
cheers,
Chris
Ken Causey wrote:
It is a precondition script whose goal is to try to prevent access to an image unless you are viewing it embedded within a page of my site.
A simpler solution is just to look at your logs every now and then and bitch at people who are hijacking images ;-)
The closest I've been able to come to this goal is to add a value to the session within the page and check in the precondition script for the image that the value is defined. Although not ideal this works sufficiently.
I think that's about as good as it'll get, HTTP and HTML are not designed to do what you want them to...
Where I'm running into the problem I described above is that I wanted to exempt managers from the check for the session variable. The obvious way to do that seemed to be to check the role of the user.
Indeed, but that's a nigh-on impossible task given the way HTTP and HTML work together...
I welcome any alternatives you can suggest.
Hmmm, why do you care so much about these images being hijacked? cheers, Chris
On Thu, 2003-09-04 at 03:54, Chris Withers wrote:
Ken Causey wrote:
It is a precondition script whose goal is to try to prevent access to an image unless you are viewing it embedded within a page of my site.
A simpler solution is just to look at your logs every now and then and bitch at people who are hijacking images ;-)
See below for why that is not so easy.
The closest I've been able to come to this goal is to add a value to the session within the page and check in the precondition script for the image that the value is defined. Although not ideal this works sufficiently.
I think that's about as good as it'll get, HTTP and HTML are not designed to do what you want them to...
Where I'm running into the problem I described above is that I wanted to exempt managers from the check for the session variable. The obvious way to do that seemed to be to check the role of the user.
Indeed, but that's a nigh-on impossible task given the way HTTP and HTML work together...
I don't understand why. In the past I have made such checks in DTML and ZPT pages and it seemed to work fine. Is it not a common task to have a page that has different behaviour based on the roles of the user?
I welcome any alternatives you can suggest.
Hmmm, why do you care so much about these images being hijacked?
Because past experience has told me it will happen. The most common occurrence is that eBay users will use my pictures and bandwidth rather than go to the trouble of making and hosting their own. This will be exacerbated by the fact that I plan myself to post items on eBay as a source of promotion. I really don't care to have to contact eBay all the time to complain about this or have to scan logs for the possibility. There are better ways to spend my time. So my preference is to find a technological solution. Ken
cheers,
Chris
Ken Causey wrote:
Indeed, but that's a nigh-on impossible task given the way HTTP and HTML work together...
I don't understand why. In the past I have made such checks in DTML and ZPT pages and it seemed to work fine. Is it not a common task to have a page that has different behaviour based on the roles of the user?
HTTP is stateless. It has no notion of whether or not the request for an image is within a page or not. Yeah, you can set a session variable or some other sort of cookie, but if your image is anonymously viewable, that may well not help you.
Hmmm, why do you care so much about these images being hijacked?
Because past experience has told me it will happen. The most common occurrence is that eBay users will use my pictures and bandwidth rather than go to the trouble of making and hosting their own. This will be exacerbated by the fact that I plan myself to post items on eBay as a source of promotion. I really don't care to have to contact eBay all the time to complain about this or have to scan logs for the possibility. There are better ways to spend my time. So my preference is to find a technological solution.
*shrugs* Well, I guess you could write an alternative security policy for Zope, but you probably don't want to be doing that... The only thign I can think of is to drop a view short lived cookie when you render your page and check for that when you decide whether or not to show the image. Chris
On Fri, 2003-09-05 at 07:47, Chris Withers wrote:
Ken Causey wrote:
Indeed, but that's a nigh-on impossible task given the way HTTP and HTML work together...
I don't understand why. In the past I have made such checks in DTML and ZPT pages and it seemed to work fine. Is it not a common task to have a page that has different behaviour based on the roles of the user?
HTTP is stateless. It has no notion of whether or not the request for an image is within a page or not. Yeah, you can set a session variable or some other sort of cookie, but if your image is anonymously viewable, that may well not help you.
Thanks for your continued explanation. Now that I think about it the example that I'm thinking of required authentication to view the page at all which explains why role information was available. In this case as you are aware I'm trying to have a mixture of anonymous and authenticated and clearly that's where I'm running into trouble. Sorry for my slow understanding. Ken
Chris
participants (3)
-
Chris Withers -
Jamie Heilman -
Ken Causey