Si,
>...to change the permission structure of the core OFBiz >applications and try to get those incorporated back into OFBiz. As tempting as this idea sounded to me first(when I started tweaking with the security stuff), it wouldn't be the right way to go. For me to push a feature back into the core OfBiz framework, it needs to pass my own scrutiny. The current OfBiz security implementation is just fine & my custom mods are very specific to our client. So I don't see the need to put my security implementation back into OfBiz. Given my situation, I'm sure that the 2 chocies I'm left with are 1. Use system login's for services. There is support already built-in 2. Modify the services I'll be using to use my security principles Si, have a look at LoginServices.userLogin, the code actually does something special with system login's. Let me know what you think. I'm looking for confirmation whether this would be a good way to provide security to services which are not in the realm of the logged in users security principles. Thanks Ashish Hareet -------- Original Message -------- Ashish, Again, just my personal opinion, but I think you've formulated your problem in a way that permits only one answer. If you must keep the core as-is AND you need a different permission structure for their users, then it seems that the way you've done it is the only solution. I still think the better solution would have been to change the permission structure of the core OFBiz applications and try to get those incorporated back into OFBiz. You could have avoided essentially building two security frameworks--one that originally came with OFBiz, one that you built on top of it which relies on pushing in arbitrary user logins. This is one advantage of working with open source--you don't have to keep the core "as is" but can tailor it for your needs or improve upon it. _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Ashish,
I'm sorry, this is where my knowledge of OFBiz fails me. I'm not sure why there is this special treatment for system logins. It is set to disabled from the seed data, so perhaps it is an older way of doing things. But it's better if David & Andy can weigh in on this. As for your two options, just go with the ones which takes less time. You would know your specific needs best... Si Ashish Hareet wrote: >Si, > > > >>...to change the permission structure of the core OFBiz >>applications and try to get those incorporated back into OFBiz. >> >> > >As tempting as this idea sounded to me first(when I started tweaking with >the security stuff), it wouldn't be the right way to go. For me to push >a feature back into the core OfBiz framework, it needs to pass my own >scrutiny. The current OfBiz security implementation is just fine & >my custom mods are very specific to our client. So I don't see the need >to put my security implementation back into OfBiz. > >Given my situation, I'm sure that the 2 chocies I'm left with are >1. Use system login's for services. There is support already built-in >2. Modify the services I'll be using to use my security principles > >Si, have a look at LoginServices.userLogin, the code actually does >something special with system login's. Let me know what you think. > >I'm looking for confirmation whether this would be a good way to >provide security to services which are not in the realm of the >logged in users security principles. > >Thanks >Ashish Hareet > > > > >-------- Original Message -------- >Ashish, > >Again, just my personal opinion, but I think you've formulated your >problem in a way that permits only one answer. If you must keep the >core as-is AND you need a different permission structure for their >users, then it seems that the way you've done it is the only solution. > >I still think the better solution would have been to change the >permission structure of the core OFBiz applications and try to get those >incorporated back into OFBiz. You could have avoided essentially >building two security frameworks--one that originally came with OFBiz, >one that you built on top of it which relies on pushing in arbitrary >user logins. > >This is one advantage of working with open source--you don't have to >keep the core "as is" but can tailor it for your needs or improve upon it. > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
The system accounts are for special purpose maintenance services that run and such, and should not ever be used in things involving user interaction. In fact, the permissions really should be changed or the user should be associated with permissions for the service the user needs to run. Not doing so means that the real user is not authenticated in the logic layer, and that is a really big security and auditability issue. In fact, it may even violate certain new standards, even though not all companies really have to abide by them yet. If you are constrained by something like the Sarbanes-Oxley, this is certainly out of the question. In fact, if you do credit card processing for Visa or MasterCard cards then unique user login credentials and traceability are a really big deal, and if audited could cause problems. -David On Aug 1, 2005, at 6:06 PM, Si Chen wrote: > Ashish, > > I'm sorry, this is where my knowledge of OFBiz fails me. I'm not > sure why there is this special treatment for system logins. It is > set to disabled from the seed data, so perhaps it is an older way > of doing things. But it's better if David & Andy can weigh in on > this. > > As for your two options, just go with the ones which takes less > time. You would know your specific needs best... > > Si > > Ashish Hareet wrote: > > >> Si, >> >> >> >>> ...to change the permission structure of the core OFBiz >>> applications and try to get those incorporated back into OFBiz. >>> >>> >> >> As tempting as this idea sounded to me first(when I started >> tweaking with the security stuff), it wouldn't be the right way to >> go. For me to push >> a feature back into the core OfBiz framework, it needs to pass my own >> scrutiny. The current OfBiz security implementation is just fine & >> my custom mods are very specific to our client. So I don't see the >> need >> to put my security implementation back into OfBiz. >> >> Given my situation, I'm sure that the 2 chocies I'm left with are >> 1. Use system login's for services. There is support already built-in >> 2. Modify the services I'll be using to use my security principles >> >> Si, have a look at LoginServices.userLogin, the code actually does >> something special with system login's. Let me know what you think. >> >> I'm looking for confirmation whether this would be a good way to >> provide security to services which are not in the realm of the >> logged in users security principles. >> >> Thanks >> Ashish Hareet >> >> >> >> >> -------- Original Message -------- >> Ashish, >> >> Again, just my personal opinion, but I think you've formulated >> your problem in a way that permits only one answer. If you must >> keep the core as-is AND you need a different permission structure >> for their users, then it seems that the way you've done it is the >> only solution. >> I still think the better solution would have been to change the >> permission structure of the core OFBiz applications and try to get >> those incorporated back into OFBiz. You could have avoided >> essentially building two security frameworks--one that originally >> came with OFBiz, one that you built on top of it which relies on >> pushing in arbitrary user logins. >> >> This is one advantage of working with open source--you don't have >> to keep the core "as is" but can tailor it for your needs or >> improve upon it. >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Free forum by Nabble | Edit this page |