Pl unsubscribe

[Kishor Das]

--- On Fri, 5/1/09, David E Jones <[hidden email]> wrote:

From: David E Jones <[hidden email]>
Subject: Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./ config/ data/ entitydef/ security/ servicedef/ widget/example/
To: [hidden email]
Date: Friday, May 1, 2009, 4:18 AM


I don't think it is common that permissions checked in the UI are different than permissions checked when the input from the UI is processed. In fact, I don't think I've ever run into that problem.

The problem I have run into over and over is that in almost every toolkit and framework around (with just a few exceptions) you have to configure or code the permission checks twice, and they often get accidently out of sync (causing either usability problems or security vulnerabilities).

If we're going to talk about extensions to the form widget or other things for security purposes, I think we should talk about  this redundancy problem because it IS an issue for the framework and one that people talk about when comparing the OFBiz framework to certain competing modern frameworks...

-David


On Apr 30, 2009, at 4:42 PM, Adrian Crum wrote:

> No, I'm not saying I disagree with you. You totally missed my point. I don't think anyone is suggesting removing permissions checking from the UI or the services. Let's get that settled right away.
>
> Jacopo is asking for a way to control the display of screen widgets based on the user's permissions. You said: "The trick is how do we setup permissions so that we set them up once and they function in both places?" Maybe I'm misunderstanding your question. It sounds to me like you're suggesting a single method could be used in both scenarios, so I responded that the requirements are different - so a single method wouldn't work.
>
> We're already using permissions to control the UI - and they are the same ones used in the service calls. The problem is, it's hard to implement. I believe all that's being suggested here is some new widget attributes or something to make it easier.
>
> -Adrian
>
> David E Jones wrote:
>> On Apr 30, 2009, at 4:09 PM, Adrian Crum wrote:
>>> David E Jones wrote:
>>>> In other words, it is nice to check permissions on the client side and/or show permission impact in the UI, but that just improves the UI... it doesn't actually enforce any of those permissions checks because it is really easy to change HTML and/or spoof a request (ie users with valid credentials that can do other things could then get around permissions that are only checked in the UI).
>>>
>>> I think Jacopo's interest is an improved UI. Why render a Create New button when the user doesn't have the permission to create anything?
>> Yeah, that's what I said... ie with phrases like "that just improves the UI" and "in the UI for user convenience".
>>>> The trick is how do we setup permissions so that we set them up once and they function in both places (ie in the input processing for the actual security, and in the UI for user convenience)?
>>>
>>> Is that even possible? The UI might contain multiple paths to follow, with each path requiring a different permission. Service invocations are generally a single path with a single permission.
>>>
>>> In other words, the UI might need to know the user's create, update, and delete permissions in order to render the screen, but the user action will result in only one service invocation - which requires only one of those user permissions.
>>>
>>> I thought about this a while back, and toyed with the idea of making the screen widgets permissions-aware.
>> So, are you saying that you disagree with what I wrote about the purposes of permissions in different places, ie:
>> 1. input processing: for security
>> 2. UI artifacts: for user convenience (improved UI)
>> Maybe what I wrote wasn't clear enough, so I'll say it again: permission checking in the UI is USELESS for security, it only helps for an improved user experience.
>> I would even go so far as to assert that if anyone doesn't understand this then they don't understand how web-based applications work, and the applications they write will be full of security holes.
>> This is why in OFBiz we REQUIRE security for services (or other input processing logic) and it is OPTIONAL in the UI.
>> -David

[Ashish Vijaywargiya]

Before sending emails at least you should read what others has referred you.
If you don't understand how to unsubscribe emails from mailing list (after
reading the content) or facing some problem then you can ask questions
instead of sending any emails from other thread.

Divesh already shared link with you that can help you to understand how to
unsubscribe from mailing list.
Here I am sharing link once again :
http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists

Can you read the details present on the above page ?
If not then read further details shown below :

The above has an icon "Unsubscribe".
Right click on that and then copy email address.

And send the email to the copied email address from your email address which
has been subscribed on the mailing list.
You will get an email in next few seconds(Probably 15 or 30 seconds) to
unsubscribe from the mailing list.
Resend that email as it is by clicking "Reply" button from your mail client.

This step comes into picture only to get confirmation from your behalf
through email.

Mailing list are maintained by a program and it handles your request
automatically .
This is all from my side.

From next time don't send email by using any threads content and saying "Pl
unsubscribe".
From above details still you are unable to unsubscribe then send me your
user credentials, I will do the needful on your behalf ;).

Thanks !
--
Ashish


On Fri, May 1, 2009 at 9:47 AM, Kishor Das <[hidden email]> wrote:

>
>
> --- On Fri, 5/1/09, David E Jones <[hidden email]> wrote:
>
> From: David E Jones <[hidden email]>
> Subject: Re: svn commit: r770084 - in /ofbiz/trunk/framework/example: ./
> config/ data/ entitydef/ security/ servicedef/ widget/example/
> To: [hidden email]
> Date: Friday, May 1, 2009, 4:18 AM
>
>