I guess if you tie you Gmail or Facebook into the login proecess of
ofbiz I can see a relevance.
How many such request do you get from your
customerserv...@yourdomain.com. Yourdomain being the one you have.
Raj Saini sent the following on 8/4/2011 6:24 PM:
> I agree with you Mike. Every week I get
Ok like the see the jira you create.
Mike sent the following on 8/4/2011 4:25 PM:
> BJ, I fail to see how this could possibly be a feature. Right now,
> I'm at the level where I fiddle around with the code. As a new user,
> should I be expected to have to review the code to see if it stands up
>
I agree with you Mike. Every week I get couple of mails from Gmail and
FB telling me that I had requested to rest my password and click on a
link to confirm the request and I simply ignore such mails as I know I
never asked to change my password. Imagine, if Gmail changes my password
every time
BJ, I fail to see how this could possibly be a feature. Right now,
I'm at the level where I fiddle around with the code. As a new user,
should I be expected to have to review the code to see if it stands up
to security standards? I don't know much, but I do know when
something isn't right, and t
Yes david if it is a bug, but by your definition many times this is a
fearture.
My point of the second paragraph that you did not include
1)part of the solution providing a way to circomvent security isssues
not part of ofbiz but how one sets up ofbiz
2)the issues are addressed if one reads the cod
On Aug 4, 2011, at 6:39 AM, BJ Freeman wrote:
> It sounds like you speaking of Ofbiz as a finished product, in which
> case I agree with you first paragraph. However Ofbiz is not a finished
> product and is meant for Consultants to setup for end users. The
> consultant should know this informatio
It sounds like you speaking of Ofbiz as a finished product, in which
case I agree with you first paragraph. However Ofbiz is not a finished
product and is meant for Consultants to setup for end users. The
consultant should know this information and make the application they
setup for their client f
Thanks Ruth. Sounds like you tweaked the system to prevent this admin
reset issue. I would think that the password reset should only apply
to ecommerce customers. Sounds like a code change will be required.
On Sat, Jul 30, 2011 at 1:24 PM, Ruth Hoffman wrote:
> Hi Mike:
> Not sure if there is
Sorry for the late response (vacation). I understand what you saying
that it is not a good idea to use generic or group accounts as much as
possible.. However, it should not be so easy for users of an ERP to
shoot themselves in the foot. This sounds like a gaping security hole,
or at least a major
looking at the current trunk the login, checks the party then looks in
contactmech for the Primary Email address.
The contact Primary Email address set in the party is used to put the
incoming emails into that party or party group.
so if you have a party group of Sales, you should associate the emp
Hi Mike:
Not sure if there is a way to turn this off, but on my 9.04 production
system I changed the default code so that the admin user had to be
logged in as admin before the password is reset. I also changed the way
the forgot password works...basically my implementation ignores requests
to
>From a data security perspective your statement about 'Any organization
would have generic accounts' is dangerous, IMHO.
If under stricter data security regulations, you would first of all want
traceability of who did what in the system, hence you want individual
accounts. And initiatives like th
even if someone request a password for admin it will only go to the
email account specified, in the profile.
I do run a nightly service that is like my own dictionary service for
passwords that are common. Then the systems sends a password reset to
the email.
BJ Freeman sent the following on 7/30
put a flag on the login entity, canresetpassword.
it is only set true when the customer loging is first created.
This way others not normally able to canresetpassword can be manually set
can also add properties like canresetinternalorgpasswrod
so an scheduled service can verify nightly that the rul
They may have a party Sales, at least in my systems, the login is email
addresses. it is harder for dictionary attracts to be effective.
Mike sent the following on 7/30/2011 7:41 AM:
> There must be something more. Any organization would have generic
> logins, like "sales", or it would be easy t
There must be something more. Any organization would have generic
logins, like "sales", or it would be easy to guess employee logins
from the "about us" page. It makes sense that the password reset
should be intended ONLY for customers, not (any) system-type login.
I would think that the passwor
for production systems do not use "admin" as a lognin.
it is never created.
Mike sent the following on 7/30/2011 12:10 AM:
> Why is it that *any* user can, using the password reset or "Forgot
> Your Password" can actually force "admin" to change the password? Is
> there a way to turn this off?
>
Why is it that *any* user can, using the password reset or "Forgot
Your Password" can actually force "admin" to change the password? Is
there a way to turn this off?
18 matches
Mail list logo
