That ant target to setup a user would be cool (and hopefully not too
hard to implement... I don't know as I've never tried). If we're going
to do that for seed-only (or seed, ext) data loading why not also get
a username instead of using admin? Having the admin user in demo data
is great, but for other installations it's nice to not have any of the
OOTB users (except the system user that should be part of seed data),
just new users that are setup that are specific to the organization.
So, yeah, sounds like a good plan.
-David
On Jan 30, 2009, at 2:45 AM, Jacopo Cappellato wrote:
I just spent some more time thinking about this and I would like to
share with you the following idea:
1) add a new ant task that prompts the user to enter a password for
the admin user: the password will then be stored in the db
2) the above task will be executed the seed-initial target is run;
if the password is not provided, the admin user is not created
3) running run-install (demo data) will automatically set the admin
password to "ofbiz" as it is now
Does it make sense?
Jacopo
On Jan 26, 2009, at 12:21 AM, Jacopo Cappellato wrote:
I can understand the concerns about security but... since the
passwords are loaded only by the seed-initial target (aka "ant run-
install-extseed") I'd say that, if you run that task, it should be
pretty clear what you are doing.
A framework upgrade (aka "svn up framework" and "ant run-install-
seed") will not be affected by this change.
Actually, the "admin" user will be created (if not already there)
but with empty password... hmmm, is it the concern about the
security hole? Yes, this could be an issue, but only for existing
db without admin user already defined.
However I think we need to find a compromise so that it will be
possible to log in into a framework only setup.
Any suggestions? (maybe just adding a clear message in the ant
output that explains what is happening when you run that task?
Jacopo
On Jan 25, 2009, at 9:59 PM, Adrian Crum wrote:
I suggested having the admin user login and password in the
framework. A couple of people responded that doing so would open
up a security hole. I asked how a user would log into a new
installation if there was no initial user login and password. The
discussion stopped there.
-Adrian
--- On Sun, 1/25/09, David E Jones <david.jo...@hotwaxmedia.com>
wrote:
From: David E Jones <david.jo...@hotwaxmedia.com>
Subject: Re: Question about hashed passwords in seed data
To: "dev@ofbiz.apache.org" <dev@ofbiz.apache.org>
Cc: "dev@ofbiz.apache.org" <dev@ofbiz.apache.org>
Date: Sunday, January 25, 2009, 12:42 PM
Maybe you understood incorrectly, if you are referring to
what I think you are.
-David
On Jan 25, 2009, at 13:01, Adrian Crum
<adrian.c...@yahoo.com> wrote:
--- On Sun, 1/25/09, Jacopo Cappellato
<jacopo.cappell...@hotwaxmedia.com> wrote:
Also, I would like to move the UserLogin record
for the
"admin" and "system" UserLogin
(including the relevant entries in the
PasswordSecurityData.xml file) from the
securityext to the
security component, i.e. from the applications to
the
framework.
In this way we will be able to log in to the
webtools
application even if we are running a framework
only version
of OFBiz.
I suggested that some time ago and the reply was that
there were to be no user login IDs or passwords supplied
with the framework.
-Adrian
