Re: Moving securityext to the framework
Hi David, inline > Please keep in mind that is just your document. There is no such thing as > implicit agreement, and if there are disagreements on the mailing list IMO > that is just as valid as someone going in and changing your document (and > most people would probably consider it less rude too, which is maybe why no > one has made changes there). > > BTW, looking through those... where are the CMS related requirements? What > sorts of business activities drive these requirements? > > Actually, to be more accurate, I wouldn't call any of the things you listed > there requirements, they all look like designs to me, ie solutions to the > problems rather than the problems themselves. The end-user requirements list I have written was only intended to start to define what the end-user will be able to do with the framework-only. This is what we really need right now; of course I can replace the "can" with "shall" if you think this will help (I really don't). The list has already been useful at least because Adrian has suggested some changes (may be adding a comment on the Confluence page would be better) so, please, let's continue using it and please, everybody be rude! Add comments or even change it. I did not write having in mind it was perfect but just a startup of the a requirements elicitation process. > And what about those who not only don't care either way about CMS, but really > don't want to bother with CMS in the system? One way or another you're sure > to get complaints... Why should I have compliants from people that will have a CMS base system and a set of selectable additional components that add the functionalities they need? The content component, as it is now, is something that cannot be (easily) removed from OFBiz so ALL users should somehow bother with it. Even the help system is based on the content component. > That is an interesting opinion, and it's great that you have been looking > into this. Could you share what you have based this opinion on, it might be > enlightening to others too. This comes just from what I have figured out looking a little bit at the communities around products as Drupal, Joomla, OpenCms, Magento etc. I may be wrong, for sure I am far from being a web analyst. But I have seen e-commerce modules to be pluggable into CMS products never the other way around. > For example, one specific idea might be to move some of the email stuff from > content to the framework somewhere. Sending and receiving emails is pretty > low-level, though that doesn't mean we'd want to move all of it as the > CommunicationEvent stuff is definitely higher level and ties to many many > other things in the system, and that's a much harder line to draw. A similar idea is just what originated my frst mail in this thread. I did see that the send forgotten password email is in the application/securityext and suggested to move to framework/security. To have the forgotten password mail in the framework we should have the email system as well for sure. So here we are on the same page. So moving forward now. I have seen an even more basic item we should agree: Do we want the framework-only to be a library only, not directly runnable/usable without an additional application installed or we want the framework-only to be directly usable with a few set of functionality? -Bruno
Re: Moving securityext to the framework
--- On Sun, 1/3/10, David E Jones wrote: > On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote: > > > --- On Sun, 1/3/10, David E Jones > wrote: > >> One way or another if we're moving things around, > >> especially moving higher level stuff into the > framework, > >> then we should definitely discuss it first and > even try to > >> reach a consensus around it. > >> > >> For example, one specific idea might be to move > some of the > >> email stuff from content to the framework > somewhere. Sending > >> and receiving emails is pretty low-level, though > that > >> doesn't mean we'd want to move all of it as the > >> CommunicationEvent stuff is definitely higher > level and ties > >> to many many other things in the system, and > that's a much > >> harder line to draw. > >> > >> For the most part the dividing line between > framework and > >> the base applications is that business-driven > things stay in > >> the apps, and technical facilitation and > interfacing lives > >> in the framework. If we want to change that, it > would be a > >> big change, and you can certainly expect some > disagreement. > > > > This is the same thing I tried to suggest. The > framework should include only those things needed to get an > application to run, and not include application code. > > > > From my perspective, sending and receiving emails is > an application. It could run on top of the framework, and > other applications could utilize it. > > Aren't most programs that run on top of an operating system > applications? How does that help us draw the line? > > Also if email is a higher level function that should only > be supported on an application level, what about MCA rules > and email libraries in the Java API? Aren't those both > pretty low level things? > > Doesn't that muddy the distinction more than clarify it? I'm sure everyone has their own mental picture of where that line is drawn. In my mind, I picture the framework composed of only the entity engine, service engine, the rendering engine, the security framework, and the webtools and example applications. Email could be a component that runs on top of the framework and that other components use. In my mind that is a clear distinction. There is no doubt others won't see it that way. -Adrian
Re: Moving securityext to the framework
On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote: > --- On Sun, 1/3/10, David E Jones wrote: >> One way or another if we're moving things around, >> especially moving higher level stuff into the framework, >> then we should definitely discuss it first and even try to >> reach a consensus around it. >> >> For example, one specific idea might be to move some of the >> email stuff from content to the framework somewhere. Sending >> and receiving emails is pretty low-level, though that >> doesn't mean we'd want to move all of it as the >> CommunicationEvent stuff is definitely higher level and ties >> to many many other things in the system, and that's a much >> harder line to draw. >> >> For the most part the dividing line between framework and >> the base applications is that business-driven things stay in >> the apps, and technical facilitation and interfacing lives >> in the framework. If we want to change that, it would be a >> big change, and you can certainly expect some disagreement. > > This is the same thing I tried to suggest. The framework should include only > those things needed to get an application to run, and not include application > code. > > From my perspective, sending and receiving emails is an application. It could > run on top of the framework, and other applications could utilize it. Aren't most programs that run on top of an operating system applications? How does that help us draw the line? Also if email is a higher level function that should only be supported on an application level, what about MCA rules and email libraries in the Java API? Aren't those both pretty low level things? Doesn't that muddy the distinction more than clarify it? -David
Re: Moving securityext to the framework
--- On Sun, 1/3/10, David E Jones wrote: > One way or another if we're moving things around, > especially moving higher level stuff into the framework, > then we should definitely discuss it first and even try to > reach a consensus around it. > > For example, one specific idea might be to move some of the > email stuff from content to the framework somewhere. Sending > and receiving emails is pretty low-level, though that > doesn't mean we'd want to move all of it as the > CommunicationEvent stuff is definitely higher level and ties > to many many other things in the system, and that's a much > harder line to draw. > > For the most part the dividing line between framework and > the base applications is that business-driven things stay in > the apps, and technical facilitation and interfacing lives > in the framework. If we want to change that, it would be a > big change, and you can certainly expect some disagreement. This is the same thing I tried to suggest. The framework should include only those things needed to get an application to run, and not include application code. >From my perspective, sending and receiving emails is an application. It could >run on top of the framework, and other applications could utilize it. -Adrian
Re: Moving securityext to the framework
On Jan 3, 2010, at 3:53 AM, Bruno Busco wrote: > When I sayd "at least me" I should have said "To implement the > framework-only distribution end-user requirements here > http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"; > We should agree or change what is written there and then work to implement it. Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there). BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements? Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves. > The framework-only work should of course generate two workproducts: > - A standalone framework implementing the requirements > - A set of additional components, each with its declared dependencies, > that can be plugged in the framework-only installation. > > For my next project all I would like to do is to select the newly > needed components and plug them in the framework-only. > > The sets of components framework+party+content+commonext should give > us a basic configuration that, from the user POV should be similar to > a CMS system but powered by OFBiz. And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints... > This CMS configuration, IMO, should have the greatest number of > potential users and, for this reason, should receive a greater > contribution from a greater community. That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too. > This configuration is also what we would need to run the OFBiz web > site itself (if we are still interested in getting this up and > running). > > Of course, as you say, there are some things in the selected > components (framework, party, content, commonext) that are not > required. These parts are, for sure, the ones that do not let the > database to be even created because depends on other components. There > are entities that should be moved away from party as the complete > org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other > that should be extended in other components. Again, that's based on your designs which are based on requirements you haven't shared yet. > So coming to your question: "what should we change in how we're doing things?" > May be nothing. Just discuss/agree on the requirements for the > framework-only and then start working on a branch. That sounds like a change to me... One way or another if we're moving things around, especially moving higher level stuff into the framework, then we should definitely discuss it first and even try to reach a consensus around it. For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw. For the most part the dividing line between framework and the base applications is that business-driven things stay in the apps, and technical facilitation and interfacing lives in the framework. If we want to change that, it would be a big change, and you can certainly expect some disagreement. On the other hand, you can certainly work on decoupling in the base applications in order to isolate the parts that you want to. They'll stay in the applications directory, but you can certainly make changes to make things run fine in spite of deleting or disabling other components. -David > 2010/1/2 David E Jones : >> >> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote: >> One major question is whether framework, on its own, should even be runnable as an application. In my opinion, it is a library, not an app and doesn't need to be operational on its own. >>> >>> The more we discuss about this the more I get convinced that what we >>> (or at least me) intend for framework-only distribution should be >>> better named "OFBiz-core". >>> The OFBiz-core could consist of framework + party + content + commonext. >>> >>> A distribution with these components set up is somewhat similar to >>> what I mean for a framework where developer can start building its >>> office automation application without the necessity to disable >>> anything but having all the power of the framework and
Re: Moving securityext to the framework
When I sayd "at least me" I should have said "To implement the framework-only distribution end-user requirements here http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"; We should agree or change what is written there and then work to implement it. The framework-only work should of course generate two workproducts: - A standalone framework implementing the requirements - A set of additional components, each with its declared dependencies, that can be plugged in the framework-only installation. For my next project all I would like to do is to select the newly needed components and plug them in the framework-only. The sets of components framework+party+content+commonext should give us a basic configuration that, from the user POV should be similar to a CMS system but powered by OFBiz. This CMS configuration, IMO, should have the greatest number of potential users and, for this reason, should receive a greater contribution from a greater community. This configuration is also what we would need to run the OFBiz web site itself (if we are still interested in getting this up and running). Of course, as you say, there are some things in the selected components (framework, party, content, commonext) that are not required. These parts are, for sure, the ones that do not let the database to be even created because depends on other components. There are entities that should be moved away from party as the complete org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other that should be extended in other components. So coming to your question: "what should we change in how we're doing things?" May be nothing. Just discuss/agree on the requirements for the framework-only and then start working on a branch. -Bruno 2010/1/2 David E Jones : > > On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote: > >>> One major question is whether framework, on its own, should even be >>> runnable as an application. In my opinion, it is a library, not an app >>> and doesn't need to be operational on its own. >> >> The more we discuss about this the more I get convinced that what we >> (or at least me) intend for framework-only distribution should be >> better named "OFBiz-core". >> The OFBiz-core could consist of framework + party + content + commonext. >> >> A distribution with these components set up is somewhat similar to >> what I mean for a framework where developer can start building its >> office automation application without the necessity to disable >> anything but having all the power of the framework and the "core" >> applications. > > Your "at least me" comment is right on. Consider that what you want, at least > right now, is framework + party + content + commonext. Do you think that will > be the same for your next project? Do you think that this is the same for a > majority of current and prospective users of OFBiz? > > I'd be willing to bet a good deal of money that this level of granularity is > not adequate to describe what you actually need/want, and that within each of > the parts you listed (framework, party, content, commonext) there are dozens > or hundreds of more specific things that you either want or don't want. > > Now consider that with many thousands of such things that will be wanted or > not wanted, there are an incredible number of combinations of these things. > Each combination is a potential "core" packaging of OFBiz. > > So, the question is what will be of most use to the largest number of users? > That question a good guiding thought, and because of the community nature of > this project it will of course be tempered by what contributors (committers > or not) actually decide is important to them. > > Based on that, what should we change in how we're doing things? > > -David > >
Re: Moving securityext to the framework
David E Jones wrote: On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote: One major question is whether framework, on its own, should even be runnable as an application. In my opinion, it is a library, not an app and doesn't need to be operational on its own. The more we discuss about this the more I get convinced that what we (or at least me) intend for framework-only distribution should be better named "OFBiz-core". The OFBiz-core could consist of framework + party + content + commonext. A distribution with these components set up is somewhat similar to what I mean for a framework where developer can start building its office automation application without the necessity to disable anything but having all the power of the framework and the "core" applications. Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz? I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want. Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz. So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them. Based on that, what should we change in how we're doing things? -David David, Your view ties in very much with my recent experiences. My last project just required framework + party, whereas my current project requires framework + party + workeffort. This has made me question whether it is practical to separate the components as you will never know what combination you may need. Could the problem be approached from a different angle - if unwanted components are commented out and there are dependency issues, rather than missing dependencies causing fatal startup errors at startup, how about a warning being issued instead? Cheers, Chris
Re: Moving securityext to the framework
On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote: >> One major question is whether framework, on its own, should even be >> runnable as an application. In my opinion, it is a library, not an app >> and doesn't need to be operational on its own. > > The more we discuss about this the more I get convinced that what we > (or at least me) intend for framework-only distribution should be > better named "OFBiz-core". > The OFBiz-core could consist of framework + party + content + commonext. > > A distribution with these components set up is somewhat similar to > what I mean for a framework where developer can start building its > office automation application without the necessity to disable > anything but having all the power of the framework and the "core" > applications. Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz? I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want. Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz. So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them. Based on that, what should we change in how we're doing things? -David
Re: Moving securityext to the framework
Those are exactly the type of questions I was writing concurrently Adam - thanks for bringing them up. My off the cuff response is that this isn't tomcat or jboss - it runs in the containers, but is not one itself, so what exactly would the framework do without an application sitting on top of it? I think that we should start looking at positioning this somewhat like what a JBoss stack implementation might look like - examples for Seam, examples for Hibernate, examples of security implementations, possibly even examples of content management / use of Webslinger, etc, etc. This would put it up favorably against what the framework "competition" looks like - and would likely show how much easier it is to develop applications in OFBiz vs some of these other frameworks that are supposed to be simple for people to use. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Jan 2, 2010, at 1:55 PM, Adam Heath wrote: > Ean Schuessler wrote: >> Adrian Crum wrote: >>> I don't agree that emailing forgotten passwords is like the Webtools >>> application. As you have discovered, emailing forgotten passwords >>> entails some decision making, looking up information in various >>> entities, selecting and rendering an email body template, etc. From my >>> perspective, all of those things are outside the scope of the framework. >> >> I agree. It is easy to imagine that some applications would not allow a >> password to be reset via email. It might be that the application uses >> biometrics, cryptographic signatures or who knows what. The framework >> authentication stubs should accommodate a diversity of approaches. >> >> One major question is whether framework, on its own, should even be >> runnable as an application. In my opinion, it is a library, not an app >> and doesn't need to be operational on its own. > > What is your definition of operational? A servlet container that is > listing for requests on 8009, 8080? Ready to process rmi requests? > > Is framework a *pure* library, where the application that runs on top > of it is responsible for starting any long-term, background services, > or should framework be the application wrapper? smime.p7s Description: S/MIME cryptographic signature
Re: Moving securityext to the framework
Those of us with strong Unix backgounds really don't want to see anything named "core" - so I'd say let's look for some other name. What you're pushing for Bruno - is much needed and could be a great enhancement to the usage of OFBiz. Anything that'll make it easier for people to build - non-eCommerce related applications without having to disable anything is a huge win in my book. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Jan 2, 2010, at 1:42 PM, Bruno Busco wrote: >> One major question is whether framework, on its own, should even be >> runnable as an application. In my opinion, it is a library, not an app >> and doesn't need to be operational on its own. > > The more we discuss about this the more I get convinced that what we > (or at least me) intend for framework-only distribution should be > better named "OFBiz-core". > The OFBiz-core could consist of framework + party + content + commonext. > > A distribution with these components set up is somewhat similar to > what I mean for a framework where developer can start building its > office automation application without the necessity to disable > anything but having all the power of the framework and the "core" > applications. > > -Bruno smime.p7s Description: S/MIME cryptographic signature
Re: Moving securityext to the framework
Ean Schuessler wrote: > Adrian Crum wrote: >> I don't agree that emailing forgotten passwords is like the Webtools >> application. As you have discovered, emailing forgotten passwords >> entails some decision making, looking up information in various >> entities, selecting and rendering an email body template, etc. From my >> perspective, all of those things are outside the scope of the framework. > > I agree. It is easy to imagine that some applications would not allow a > password to be reset via email. It might be that the application uses > biometrics, cryptographic signatures or who knows what. The framework > authentication stubs should accommodate a diversity of approaches. > > One major question is whether framework, on its own, should even be > runnable as an application. In my opinion, it is a library, not an app > and doesn't need to be operational on its own. What is your definition of operational? A servlet container that is listing for requests on 8009, 8080? Ready to process rmi requests? Is framework a *pure* library, where the application that runs on top of it is responsible for starting any long-term, background services, or should framework be the application wrapper?
Re: Moving securityext to the framework
> One major question is whether framework, on its own, should even be > runnable as an application. In my opinion, it is a library, not an app > and doesn't need to be operational on its own. The more we discuss about this the more I get convinced that what we (or at least me) intend for framework-only distribution should be better named "OFBiz-core". The OFBiz-core could consist of framework + party + content + commonext. A distribution with these components set up is somewhat similar to what I mean for a framework where developer can start building its office automation application without the necessity to disable anything but having all the power of the framework and the "core" applications. -Bruno
Re: Moving securityext to the framework
Adrian Crum wrote: > I don't agree that emailing forgotten passwords is like the Webtools > application. As you have discovered, emailing forgotten passwords > entails some decision making, looking up information in various > entities, selecting and rendering an email body template, etc. From my > perspective, all of those things are outside the scope of the framework. I agree. It is easy to imagine that some applications would not allow a password to be reset via email. It might be that the application uses biometrics, cryptographic signatures or who knows what. The framework authentication stubs should accommodate a diversity of approaches. One major question is whether framework, on its own, should even be runnable as an application. In my opinion, it is a library, not an app and doesn't need to be operational on its own.
Re: Moving securityext to the framework
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
What about if someone wants to implement retrieving forgotten passwords
through sms (short messaging service) instead of email? Are we going to
add telephone number to userLogin entity?
So my vote is to let forgotten password feature in applications or move
the related entities to framework.
Bilgin
Re: Moving securityext to the framework
It seems to me that a Framework+Party+Content installation would
better fit the requirements in
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution.
-Bruno
2009/12/30 Bruno Busco :
> Adrian,
> I think our divergence comes from how we imagine the framework-only being
> used.
> I imagine the framework-only installation ready to be used as soon as
> installed.
> Admin can login and start adding users, groups, set permissions.
> Users can start logging in, personalizing their home Portal pages,
> select their favourite Theme.
>
> Then admin plugs a new component in the hot-deploy (or in
> application), only a set of users can access it because others have no
> permission and do not even know about the new application.
> Then admin adds permission to users, new portlets became available to
> the users, more menus etc.
>
> May be "framework-only" is not the right name for this distribution
> but I definitively think it is what would best help the OFBiz users.
>
> -Bruno
>
>
> 2009/12/30 Adrian Crum :
>> I don't agree that emailing forgotten passwords is like the Webtools
>> application. As you have discovered, emailing forgotten passwords entails
>> some decision making, looking up information in various entities, selecting
>> and rendering an email body template, etc. From my perspective, all of those
>> things are outside the scope of the framework.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>>
>>> Adrian,
>>> I agree that this can be done in an application using the framework
>>> but this application should be located in the framework folder like
>>> the webtools application.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Adrian Crum :
All of the things you are describing could be done by an application
developer that is using the framework.
It would be wise to draw a very distinct and strict line between
framework-level functionality and application-level functionality.
-Adrian
Bruno Busco wrote:
>
> Then we should have a setPrimaryEmailAddress service defined in the
> framework (that sets the userLogin.email field) and overridden in the
> Party application that sets/create the propert PArty/ContactMech.
>
> Does this make sense?
>
> -Bruno
>
> 2009/12/30 Bruno Busco :
>>
>> Adrian,
>> the getPrimaryEmailAddress defined in the framework could return the
>> email field stored in the userLogin entity and when it is override by
>> the Party application can retrieve the address from the
>> userlLogin->Party->ContactMech chain.
>>
>> In this way we should get it working in the framawork-only also.
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco :
>>>
>>> Having the getPrimaryEmailAddress in the framework returning nothing
>>> does not let the forgotPassword feature work in the framework-only
>>> installation (no party).
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Adrian Crum :
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
>
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility
> to
> have the password emailed if forgotten.
> This is actually done in
> public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
>
> To get the email address, emailPassword(...) checks if the
> userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.
>
> So, being dependent from both party and product, emailPassword(...)
> service needs to be in applications/securityext and cannot be
> available in a framework-only distribution.
>
> Now,
> the emailPassword(...) sevice in the securityext is OK for the
> ecommerce application (that depends on party and product) but IMO is
> not the right implementation for the backoffice (and thus for the
> framework-only).
>
> I propose to do the following:
> 1) Put an email address in the userLogin entity. This would be used
> to
> retrieve the password.
> 2) Move the to the
> common component (renaming it simply "EmailSetting") and transform
> the
> actual "ProductStoreEmailSetting" into a link between ProductStore
> and
> EmailSetting.
Re: Moving securityext to the framework
Adrian,
I think our divergence comes from how we imagine the framework-only being used.
I imagine the framework-only installation ready to be used as soon as installed.
Admin can login and start adding users, groups, set permissions.
Users can start logging in, personalizing their home Portal pages,
select their favourite Theme.
Then admin plugs a new component in the hot-deploy (or in
application), only a set of users can access it because others have no
permission and do not even know about the new application.
Then admin adds permission to users, new portlets became available to
the users, more menus etc.
May be "framework-only" is not the right name for this distribution
but I definitively think it is what would best help the OFBiz users.
-Bruno
2009/12/30 Adrian Crum :
> I don't agree that emailing forgotten passwords is like the Webtools
> application. As you have discovered, emailing forgotten passwords entails
> some decision making, looking up information in various entities, selecting
> and rendering an email body template, etc. From my perspective, all of those
> things are outside the scope of the framework.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Adrian,
>> I agree that this can be done in an application using the framework
>> but this application should be located in the framework folder like
>> the webtools application.
>>
>> -Bruno
>>
>> 2009/12/30 Adrian Crum :
>>>
>>> All of the things you are describing could be done by an application
>>> developer that is using the framework.
>>>
>>> It would be wise to draw a very distinct and strict line between
>>> framework-level functionality and application-level functionality.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
>
> Adrian,
> the getPrimaryEmailAddress defined in the framework could return the
> email field stored in the userLogin entity and when it is override by
> the Party application can retrieve the address from the
> userlLogin->Party->ContactMech chain.
>
> In this way we should get it working in the framawork-only also.
>
> -Bruno
>
> 2009/12/30 Bruno Busco :
>>
>> Having the getPrimaryEmailAddress in the framework returning nothing
>> does not let the forgotPassword feature work in the framework-only
>> installation (no party).
>>
>> -Bruno
>>
>> 2009/12/30 Adrian Crum :
>>>
>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>> framework and returns nothing. The Party application can override the
>>> service to return the primary email address, if it exists.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility
to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the
userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used
to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform
the
actual "ProductStoreEmailSetting" into a link between ProductStore
and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the
userLogin
entity and retrieving the email settings accessing to the
EmailSetting
entity.
What do you think about?
-Bruno
>>>
Re: Moving securityext to the framework
I don't agree that emailing forgotten passwords is like the Webtools
application. As you have discovered, emailing forgotten passwords
entails some decision making, looking up information in various
entities, selecting and rendering an email body template, etc. From my
perspective, all of those things are outside the scope of the framework.
-Adrian
Bruno Busco wrote:
Adrian,
I agree that this can be done in an application using the framework
but this application should be located in the framework folder like
the webtools application.
-Bruno
2009/12/30 Adrian Crum :
All of the things you are describing could be done by an application
developer that is using the framework.
It would be wise to draw a very distinct and strict line between
framework-level functionality and application-level functionality.
-Adrian
Bruno Busco wrote:
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.
In this way we should get it working in the framawork-only also.
-Bruno
2009/12/30 Bruno Busco :
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application
components, I
believe this was done as part of the effort to isolate the framework
from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on
the
application code but I don't necessarily think we should have a goal
of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally
in
the
application domain back to the framework. The more that we look at
doing
the latter the more we need to consider exactly what the needs are
that
we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general
purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it,
but
please, if you see something blocking this or something that should
be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a se
Re: Moving securityext to the framework
I would recommend changing #6 to:
#6 users can change their password
and then drop 7 through 9.
But that's just my opinion.
-Adrian
Bruno Busco wrote:
OK,
back to requirements.
I tryed to write down a list of requirements here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
Could we have a discussion and possibly change them as and refine them
as required?
-Bruno
2009/12/30 Adrian Crum :
All of the things you are describing could be done by an application
developer that is using the framework.
It would be wise to draw a very distinct and strict line between
framework-level functionality and application-level functionality.
-Adrian
Bruno Busco wrote:
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.
In this way we should get it working in the framawork-only also.
-Bruno
2009/12/30 Bruno Busco :
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application
components, I
believe this was done as part of the effort to isolate the framework
from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on
the
application code but I don't necessarily think we should have a goal
of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally
in
the
application domain back to the framework. The more that we look at
doing
the latter the more we need to consider exactly what the needs are
that
we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general
purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it,
but
please, if you see something blocking this or something that should
be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a securityext code browsing I see that there is a dependence
from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party
Re: Moving securityext to the framework
Bruno Busco wrote:
> One thing we need in the framework is the possibility to create a
> userLogin with an associated email address and have the possibility to
> have the password emailed if forgotten.
> This is actually done in
> public static String emailPassword(HttpServletRequest request,
> HttpServletResponse response) {
> that is located in LoginEvents.java in securityext.
>
> To get the email address, emailPassword(...) checks if the userLoginId
> exists, then find the related party, then find a related ContactMech
> with PRIMARY_MAIL purpose.
> To get the email body and other details, emailPassword(...) starts
> from a ProductStore and gets the related ProductStoreEmailSetting.
Why not move ContactMech(and children, but not PartyContactMech*) to
framework, then have a join table between UserLogin and ContactMech?
Re: Moving securityext to the framework
Adrian,
I agree that this can be done in an application using the framework
but this application should be located in the framework folder like
the webtools application.
-Bruno
2009/12/30 Adrian Crum :
> All of the things you are describing could be done by an application
> developer that is using the framework.
>
> It would be wise to draw a very distinct and strict line between
> framework-level functionality and application-level functionality.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Then we should have a setPrimaryEmailAddress service defined in the
>> framework (that sets the userLogin.email field) and overridden in the
>> Party application that sets/create the propert PArty/ContactMech.
>>
>> Does this make sense?
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco :
>>>
>>> Adrian,
>>> the getPrimaryEmailAddress defined in the framework could return the
>>> email field stored in the userLogin entity and when it is override by
>>> the Party application can retrieve the address from the
>>> userlLogin->Party->ContactMech chain.
>>>
>>> In this way we should get it working in the framawork-only also.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco :
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
>
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. The Party application can override the
> service to return the primary email address, if it exists.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>> public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray :
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application
>>> components, I
>>> believe this was done as part of the effort to isolate the framework
>>> from
>>> any application dependencies. I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on
>>> the
>>> application code but I don't necessarily think we should have a goal
>>> of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally
>>> in
>>> the
>>> application domain back to the framework. The more that we look at
>>> doing
>>> the latter the more we need to consider exactly what the needs are
>>> that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
Hi David, devs,
I searched the SVN logs to look for a reason for those general
purpose
login and password stuff being in the application and not in the
Re: Moving securityext to the framework
OK,
back to requirements.
I tryed to write down a list of requirements here:
http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution
Could we have a discussion and possibly change them as and refine them
as required?
-Bruno
2009/12/30 Adrian Crum :
> All of the things you are describing could be done by an application
> developer that is using the framework.
>
> It would be wise to draw a very distinct and strict line between
> framework-level functionality and application-level functionality.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> Then we should have a setPrimaryEmailAddress service defined in the
>> framework (that sets the userLogin.email field) and overridden in the
>> Party application that sets/create the propert PArty/ContactMech.
>>
>> Does this make sense?
>>
>> -Bruno
>>
>> 2009/12/30 Bruno Busco :
>>>
>>> Adrian,
>>> the getPrimaryEmailAddress defined in the framework could return the
>>> email field stored in the userLogin entity and when it is override by
>>> the Party application can retrieve the address from the
>>> userlLogin->Party->ContactMech chain.
>>>
>>> In this way we should get it working in the framawork-only also.
>>>
>>> -Bruno
>>>
>>> 2009/12/30 Bruno Busco :
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
>
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. The Party application can override the
> service to return the primary email address, if it exists.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>> public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray :
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application
>>> components, I
>>> believe this was done as part of the effort to isolate the framework
>>> from
>>> any application dependencies. I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on
>>> the
>>> application code but I don't necessarily think we should have a goal
>>> of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally
>>> in
>>> the
>>> application domain back to the framework. The more that we look at
>>> doing
>>> the latter the more we need to consider exactly what the needs are
>>> that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
Hi David, devs,
I searched the SVN logs to look for a reason for those general
purpose
>>>
Re: Moving securityext to the framework
All of the things you are describing could be done by an application
developer that is using the framework.
It would be wise to draw a very distinct and strict line between
framework-level functionality and application-level functionality.
-Adrian
Bruno Busco wrote:
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.
In this way we should get it working in the framawork-only also.
-Bruno
2009/12/30 Bruno Busco :
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application components, I
believe this was done as part of the effort to isolate the framework from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on the
application code but I don't necessarily think we should have a goal of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally in
the
application domain back to the framework. The more that we look at doing
the latter the more we need to consider exactly what the needs are that
we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a securityext code browsing I see that there is a dependence from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party, Person, PartyRole,
PartyContactMech entities
-> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
the updatePassword service. This is to be sure that an admin can
always update a password, even not knowing the current password.
-> An admin permission should be checked here.
Product:
3) In the LoginEvents.java the emailPassword method is written to be
used for a ProductStore. Th
Re: Moving securityext to the framework
Like Scott said, that feature is appropriate for applications, not for
the framework. So we can create framework services for the feature that
do nothing - which can then be overridden by applications, or we can
remove the feature from the framework and implement it entirely in the
Party application (or some other application).
-Adrian
Bruno Busco wrote:
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application components, I
believe this was done as part of the effort to isolate the framework from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on the
application code but I don't necessarily think we should have a goal of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally in
the
application domain back to the framework. The more that we look at doing
the latter the more we need to consider exactly what the needs are that
we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a securityext code browsing I see that there is a dependence from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party, Person, PartyRole,
PartyContactMech entities
-> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
the updatePassword service. This is to be sure that an admin can
always update a password, even not knowing the current password.
-> An admin permission should be checked here.
Product:
3) In the LoginEvents.java the emailPassword method is written to be
used for a ProductStore. The password email should be a core feature
not used for ProductStores only.
-> Could we split this method in a framework one and an higher
level part (dedicated for a ProductStore) implemented in the Product
component?
Ecommerce:
4) In passwordemail.ftl there are few labels from ECommerce -> Since
the email password should not only be an ecommerce feature this should
be moved to Common.
Should we try to resolve these dependences and then merge to security
in the framework?
-Bruno
2009/12/11 Scott Gray :
Re: Moving securityext to the framework
Then we should have a setPrimaryEmailAddress service defined in the
framework (that sets the userLogin.email field) and overridden in the
Party application that sets/create the propert PArty/ContactMech.
Does this make sense?
-Bruno
2009/12/30 Bruno Busco :
> Adrian,
> the getPrimaryEmailAddress defined in the framework could return the
> email field stored in the userLogin entity and when it is override by
> the Party application can retrieve the address from the
> userlLogin->Party->ContactMech chain.
>
> In this way we should get it working in the framawork-only also.
>
> -Bruno
>
> 2009/12/30 Bruno Busco :
>> Having the getPrimaryEmailAddress in the framework returning nothing
>> does not let the forgotPassword feature work in the framework-only
>> installation (no party).
>>
>> -Bruno
>>
>> 2009/12/30 Adrian Crum :
>>> Or have a service - getPrimaryEmailAddress - that is defined in the
>>> framework and returns nothing. The Party application can override the
>>> service to return the primary email address, if it exists.
>>>
>>> -Adrian
>>>
>>> Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
>
> Hi Bruno,
>
> The whole point of the securityext component is to allow portions of
> security related functionality to depend on the application components, I
> believe this was done as part of the effort to isolate the framework from
> any application dependencies. I think it is perfectly fine to move
> portions
> of securityext back to the framework when there is no dependency on the
> application code but I don't necessarily think we should have a goal of
> removing the securityext component altogether.
>
> It wouldn't be possible to remove securityext without either removing
> functionality or otherwise transferring logic that is traditionally in
> the
> application domain back to the framework. The more that we look at doing
> the latter the more we need to consider exactly what the needs are that
> we
> want a framework only installation to fulfill.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>
>> Hi David, devs,
>> I searched the SVN logs to look for a reason for those general purpose
>> login and password stuff being in the application and not in the
>> framework.
>> I found they are there since the incubator time.
>>
>> What I think should be done is to merge the securityext to the
>> security component in the framework. I would like to try to do it, but
>> please, if you see something blocking this or something that should be
>> done first, or even a reason for not to do this, please advice.
>>
>> Thank you,
>> -Bruno
>>
>>
>> 2009/12/26 Bruno Busco :
>>>
>>> Scott,
>>> from a securityext code browsing I see that there is a dependence from
>>> Party, Product and Ecommerce.
>>>
>>> Party:
>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>> PartyContactMech entities
>>> -> Could be moved to Party?
>>> 2) LoginSi
Re: Moving securityext to the framework
Adrian,
the getPrimaryEmailAddress defined in the framework could return the
email field stored in the userLogin entity and when it is override by
the Party application can retrieve the address from the
userlLogin->Party->ContactMech chain.
In this way we should get it working in the framawork-only also.
-Bruno
2009/12/30 Bruno Busco :
> Having the getPrimaryEmailAddress in the framework returning nothing
> does not let the forgotPassword feature work in the framework-only
> installation (no party).
>
> -Bruno
>
> 2009/12/30 Adrian Crum :
>> Or have a service - getPrimaryEmailAddress - that is defined in the
>> framework and returns nothing. The Party application can override the
>> service to return the primary email address, if it exists.
>>
>> -Adrian
>>
>> Bruno Busco wrote:
>>>
>>> One thing we need in the framework is the possibility to create a
>>> userLogin with an associated email address and have the possibility to
>>> have the password emailed if forgotten.
>>> This is actually done in
>>> public static String emailPassword(HttpServletRequest request,
>>> HttpServletResponse response) {
>>> that is located in LoginEvents.java in securityext.
>>>
>>> To get the email address, emailPassword(...) checks if the userLoginId
>>> exists, then find the related party, then find a related ContactMech
>>> with PRIMARY_MAIL purpose.
>>> To get the email body and other details, emailPassword(...) starts
>>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>>
>>> So, being dependent from both party and product, emailPassword(...)
>>> service needs to be in applications/securityext and cannot be
>>> available in a framework-only distribution.
>>>
>>> Now,
>>> the emailPassword(...) sevice in the securityext is OK for the
>>> ecommerce application (that depends on party and product) but IMO is
>>> not the right implementation for the backoffice (and thus for the
>>> framework-only).
>>>
>>> I propose to do the following:
>>> 1) Put an email address in the userLogin entity. This would be used to
>>> retrieve the password.
>>> 2) Move the to the
>>> common component (renaming it simply "EmailSetting") and transform the
>>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>>> EmailSetting.
>>> 3) Define a new emailPassword(...) service in the common component
>>> that does things differently: using the email address in the userLogin
>>> entity and retrieving the email settings accessing to the EmailSetting
>>> entity.
>>>
>>> What do you think about?
>>>
>>> -Bruno
>>>
>>>
>>>
>>> 2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application components, I
believe this was done as part of the effort to isolate the framework from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on the
application code but I don't necessarily think we should have a goal of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally in
the
application domain back to the framework. The more that we look at doing
the latter the more we need to consider exactly what the needs are that
we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
> Hi David, devs,
> I searched the SVN logs to look for a reason for those general purpose
> login and password stuff being in the application and not in the
> framework.
> I found they are there since the incubator time.
>
> What I think should be done is to merge the securityext to the
> security component in the framework. I would like to try to do it, but
> please, if you see something blocking this or something that should be
> done first, or even a reason for not to do this, please advice.
>
> Thank you,
> -Bruno
>
>
> 2009/12/26 Bruno Busco :
>>
>> Scott,
>> from a securityext code browsing I see that there is a dependence from
>> Party, Product and Ecommerce.
>>
>> Party:
>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>> PartyContactMech entities
>> -> Could be moved to Party?
>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>> the updatePassword service. This is to be sure that an admin can
>> always update a password, even not knowing the current password.
>> -> An admin permission should be checked here.
>>
>> Product:
>> 3) In the LoginEvents.java the emailPassword method is written to be
>> used for a ProductStore. The
Re: Moving securityext to the framework
Having the getPrimaryEmailAddress in the framework returning nothing
does not let the forgotPassword feature work in the framework-only
installation (no party).
-Bruno
2009/12/30 Adrian Crum :
> Or have a service - getPrimaryEmailAddress - that is defined in the
> framework and returns nothing. The Party application can override the
> service to return the primary email address, if it exists.
>
> -Adrian
>
> Bruno Busco wrote:
>>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>> public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray :
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application components, I
>>> believe this was done as part of the effort to isolate the framework from
>>> any application dependencies. I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on the
>>> application code but I don't necessarily think we should have a goal of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally in
>>> the
>>> application domain back to the framework. The more that we look at doing
>>> the latter the more we need to consider exactly what the needs are that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
>
> Scott,
> from a securityext code browsing I see that there is a dependence from
> Party, Product and Ecommerce.
>
> Party:
> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
> PartyContactMech entities
> -> Could be moved to Party?
> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
> the updatePassword service. This is to be sure that an admin can
> always update a password, even not knowing the current password.
> -> An admin permission should be checked here.
>
> Product:
> 3) In the LoginEvents.java the emailPassword method is written to be
> used for a ProductStore. The password email should be a core feature
> not used for ProductStores only.
> -> Could we split this method in a framework one and an higher
> level part (dedicated for a ProductStore) implemented in the Product
> component?
>
> Ecommerce:
> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
> the email password should not only be an ecommerce feature this should
> be moved to Common.
>
> Should we t
Re: Moving securityext to the framework
In the framework-only there will be the webtools, the example and the
MyPortal applications.
So it is something that should allow defining new users (userLogins)
to be defined with their permissions.
As soon as I have a new user defined I need the forgot password feature working.
This is why we need it.
-Bruno
2009/12/29 Scott Gray :
> My first question is why do we need this functionality in the framework? At
> what point do we draw the line between framework and application? Emailing
> passwords sounds very much like an application feature to me.
>
> Regards
> Scott
>
> On 30/12/2009, at 11:50 AM, Bruno Busco wrote:
>
>> One thing we need in the framework is the possibility to create a
>> userLogin with an associated email address and have the possibility to
>> have the password emailed if forgotten.
>> This is actually done in
>> public static String emailPassword(HttpServletRequest request,
>> HttpServletResponse response) {
>> that is located in LoginEvents.java in securityext.
>>
>> To get the email address, emailPassword(...) checks if the userLoginId
>> exists, then find the related party, then find a related ContactMech
>> with PRIMARY_MAIL purpose.
>> To get the email body and other details, emailPassword(...) starts
>> from a ProductStore and gets the related ProductStoreEmailSetting.
>>
>> So, being dependent from both party and product, emailPassword(...)
>> service needs to be in applications/securityext and cannot be
>> available in a framework-only distribution.
>>
>> Now,
>> the emailPassword(...) sevice in the securityext is OK for the
>> ecommerce application (that depends on party and product) but IMO is
>> not the right implementation for the backoffice (and thus for the
>> framework-only).
>>
>> I propose to do the following:
>> 1) Put an email address in the userLogin entity. This would be used to
>> retrieve the password.
>> 2) Move the to the
>> common component (renaming it simply "EmailSetting") and transform the
>> actual "ProductStoreEmailSetting" into a link between ProductStore and
>> EmailSetting.
>> 3) Define a new emailPassword(...) service in the common component
>> that does things differently: using the email address in the userLogin
>> entity and retrieving the email settings accessing to the EmailSetting
>> entity.
>>
>> What do you think about?
>>
>> -Bruno
>>
>>
>>
>> 2009/12/29 Scott Gray :
>>>
>>> Hi Bruno,
>>>
>>> The whole point of the securityext component is to allow portions of
>>> security related functionality to depend on the application components, I
>>> believe this was done as part of the effort to isolate the framework from
>>> any application dependencies. I think it is perfectly fine to move
>>> portions
>>> of securityext back to the framework when there is no dependency on the
>>> application code but I don't necessarily think we should have a goal of
>>> removing the securityext component altogether.
>>>
>>> It wouldn't be possible to remove securityext without either removing
>>> functionality or otherwise transferring logic that is traditionally in
>>> the
>>> application domain back to the framework. The more that we look at doing
>>> the latter the more we need to consider exactly what the needs are that
>>> we
>>> want a framework only installation to fulfill.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>>>
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
>
> Scott,
> from a securityext code browsing I see that there is a dependence from
> Party, Product and Ecommerce.
>
> Party:
> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
> PartyContactMech entities
> -> Could be moved to Party?
> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
> the updatePassword service. This is to be sure that an admin can
> always update a password, even not knowing the current password.
> -> An admin permission should be checked here.
>
> Product:
> 3) In the LoginEvents.java the emailPassword method is written to be
> used for a ProductStore. The password email should be a core feature
> not used for ProductStores only.
> -> Could we split this method in a framework one and an higher
> level part (dedicated for a ProductStore) implemented in the Product
> component?
>
> Ecommerce:
>
Re: Moving securityext to the framework
Or have a service - getPrimaryEmailAddress - that is defined in the
framework and returns nothing. The Party application can override the
service to return the primary email address, if it exists.
-Adrian
Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application components, I
believe this was done as part of the effort to isolate the framework from
any application dependencies. I think it is perfectly fine to move portions
of securityext back to the framework when there is no dependency on the
application code but I don't necessarily think we should have a goal of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally in the
application domain back to the framework. The more that we look at doing
the latter the more we need to consider exactly what the needs are that we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it, but
please, if you see something blocking this or something that should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a securityext code browsing I see that there is a dependence from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party, Person, PartyRole,
PartyContactMech entities
-> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
the updatePassword service. This is to be sure that an admin can
always update a password, even not knowing the current password.
-> An admin permission should be checked here.
Product:
3) In the LoginEvents.java the emailPassword method is written to be
used for a ProductStore. The password email should be a core feature
not used for ProductStores only.
-> Could we split this method in a framework one and an higher
level part (dedicated for a ProductStore) implemented in the Product
component?
Ecommerce:
4) In passwordemail.ftl there are few labels from ECommerce -> Since
the email password should not only be an ecommerce feature this should
be moved to Common.
Should we try to resolve these dependences and then merge to security
in the framework?
-Bruno
2009/12/11 Scott Gray :
I guess the first thing we need to understand is why it exists in the
first
place? I'm assuming it has some dependencies on application components
that
prevent it from being in the framework (even if perhaps some of the
logic
could be moved).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
Hi,
the securityext component is actually located in the application
folder.
It implements the sending of the password remainder, password updated
services, permission groups etc. that we want available in
Re: Moving securityext to the framework
My first question is why do we need this functionality in the
framework? At what point do we draw the line between framework and
application? Emailing passwords sounds very much like an application
feature to me.
Regards
Scott
On 30/12/2009, at 11:50 AM, Bruno Busco wrote:
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
Hi Bruno,
The whole point of the securityext component is to allow portions of
security related functionality to depend on the application
components, I
believe this was done as part of the effort to isolate the
framework from
any application dependencies. I think it is perfectly fine to move
portions
of securityext back to the framework when there is no dependency on
the
application code but I don't necessarily think we should have a
goal of
removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing
functionality or otherwise transferring logic that is traditionally
in the
application domain back to the framework. The more that we look at
doing
the latter the more we need to consider exactly what the needs are
that we
want a framework only installation to fulfill.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs,
I searched the SVN logs to look for a reason for those general
purpose
login and password stuff being in the application and not in the
framework.
I found they are there since the incubator time.
What I think should be done is to merge the securityext to the
security component in the framework. I would like to try to do it,
but
please, if you see something blocking this or something that
should be
done first, or even a reason for not to do this, please advice.
Thank you,
-Bruno
2009/12/26 Bruno Busco :
Scott,
from a securityext code browsing I see that there is a dependence
from
Party, Product and Ecommerce.
Party:
1) The UserDemoData.xml file creates several Party, Person,
PartyRole,
PartyContactMech entities
-> Could be moved to Party?
2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
the updatePassword service. This is to be sure that an admin can
always update a password, even not knowing the current password.
-> An admin permission should be checked here.
Product:
3) In the LoginEvents.java the emailPassword method is written to
be
used for a ProductStore. The password email should be a core
feature
not used for ProductStores only.
-> Could we split this method in a framework one and an higher
level part (dedicated for a ProductStore) implemented in the
Product
component?
Ecommerce:
4) In passwordemail.ftl there are few labels from ECommerce ->
Since
the email password should not only be an ecommerce feature this
should
be moved to Common.
Should we try to resolve these dependences and then merge to
security
in the framework?
-Bruno
2009/12/11 Scott Gray :
I guess the first thing we need to understand is why it exists
in the
first
place? I'm assuming it has some dependencies on application
components
that
prevent it from being in the framework (even if perhaps some of
the
logic
could be moved).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
Hi,
the securityext component is actually located in the application
folder.
It implements
Re: Moving securityext to the framework
One thing we need in the framework is the possibility to create a
userLogin with an associated email address and have the possibility to
have the password emailed if forgotten.
This is actually done in
public static String emailPassword(HttpServletRequest request,
HttpServletResponse response) {
that is located in LoginEvents.java in securityext.
To get the email address, emailPassword(...) checks if the userLoginId
exists, then find the related party, then find a related ContactMech
with PRIMARY_MAIL purpose.
To get the email body and other details, emailPassword(...) starts
from a ProductStore and gets the related ProductStoreEmailSetting.
So, being dependent from both party and product, emailPassword(...)
service needs to be in applications/securityext and cannot be
available in a framework-only distribution.
Now,
the emailPassword(...) sevice in the securityext is OK for the
ecommerce application (that depends on party and product) but IMO is
not the right implementation for the backoffice (and thus for the
framework-only).
I propose to do the following:
1) Put an email address in the userLogin entity. This would be used to
retrieve the password.
2) Move the to the
common component (renaming it simply "EmailSetting") and transform the
actual "ProductStoreEmailSetting" into a link between ProductStore and
EmailSetting.
3) Define a new emailPassword(...) service in the common component
that does things differently: using the email address in the userLogin
entity and retrieving the email settings accessing to the EmailSetting
entity.
What do you think about?
-Bruno
2009/12/29 Scott Gray :
> Hi Bruno,
>
> The whole point of the securityext component is to allow portions of
> security related functionality to depend on the application components, I
> believe this was done as part of the effort to isolate the framework from
> any application dependencies. I think it is perfectly fine to move portions
> of securityext back to the framework when there is no dependency on the
> application code but I don't necessarily think we should have a goal of
> removing the securityext component altogether.
>
> It wouldn't be possible to remove securityext without either removing
> functionality or otherwise transferring logic that is traditionally in the
> application domain back to the framework. The more that we look at doing
> the latter the more we need to consider exactly what the needs are that we
> want a framework only installation to fulfill.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
>
>> Hi David, devs,
>> I searched the SVN logs to look for a reason for those general purpose
>> login and password stuff being in the application and not in the
>> framework.
>> I found they are there since the incubator time.
>>
>> What I think should be done is to merge the securityext to the
>> security component in the framework. I would like to try to do it, but
>> please, if you see something blocking this or something that should be
>> done first, or even a reason for not to do this, please advice.
>>
>> Thank you,
>> -Bruno
>>
>>
>> 2009/12/26 Bruno Busco :
>>>
>>> Scott,
>>> from a securityext code browsing I see that there is a dependence from
>>> Party, Product and Ecommerce.
>>>
>>> Party:
>>> 1) The UserDemoData.xml file creates several Party, Person, PartyRole,
>>> PartyContactMech entities
>>> -> Could be moved to Party?
>>> 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in
>>> the updatePassword service. This is to be sure that an admin can
>>> always update a password, even not knowing the current password.
>>> -> An admin permission should be checked here.
>>>
>>> Product:
>>> 3) In the LoginEvents.java the emailPassword method is written to be
>>> used for a ProductStore. The password email should be a core feature
>>> not used for ProductStores only.
>>> -> Could we split this method in a framework one and an higher
>>> level part (dedicated for a ProductStore) implemented in the Product
>>> component?
>>>
>>> Ecommerce:
>>> 4) In passwordemail.ftl there are few labels from ECommerce -> Since
>>> the email password should not only be an ecommerce feature this should
>>> be moved to Common.
>>>
>>> Should we try to resolve these dependences and then merge to security
>>> in the framework?
>>>
>>> -Bruno
>>>
>>>
>>> 2009/12/11 Scott Gray :
I guess the first thing we need to understand is why it exists in the
first
place? I'm assuming it has some dependencies on application components
that
prevent it from being in the framework (even if perhaps some of the
logic
could be moved).
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 11/12/2009, at 11:41 PM, Bruno Busco wrote:
> Hi,
> the securityext component is actually located in the application
> folder.
> It implements the sending of the password re
Re: Moving securityext to the framework
Hi Bruno, The whole point of the securityext component is to allow portions of security related functionality to depend on the application components, I believe this was done as part of the effort to isolate the framework from any application dependencies. I think it is perfectly fine to move portions of securityext back to the framework when there is no dependency on the application code but I don't necessarily think we should have a goal of removing the securityext component altogether. It wouldn't be possible to remove securityext without either removing functionality or otherwise transferring logic that is traditionally in the application domain back to the framework. The more that we look at doing the latter the more we need to consider exactly what the needs are that we want a framework only installation to fulfill. Regards Scott HotWax Media http://www.hotwaxmedia.com On 30/12/2009, at 6:11 AM, Bruno Busco wrote: Hi David, devs, I searched the SVN logs to look for a reason for those general purpose login and password stuff being in the application and not in the framework. I found they are there since the incubator time. What I think should be done is to merge the securityext to the security component in the framework. I would like to try to do it, but please, if you see something blocking this or something that should be done first, or even a reason for not to do this, please advice. Thank you, -Bruno 2009/12/26 Bruno Busco : Scott, from a securityext code browsing I see that there is a dependence from Party, Product and Ecommerce. Party: 1) The UserDemoData.xml file creates several Party, Person, PartyRole, PartyContactMech entities -> Could be moved to Party? 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in the updatePassword service. This is to be sure that an admin can always update a password, even not knowing the current password. -> An admin permission should be checked here. Product: 3) In the LoginEvents.java the emailPassword method is written to be used for a ProductStore. The password email should be a core feature not used for ProductStores only. -> Could we split this method in a framework one and an higher level part (dedicated for a ProductStore) implemented in the Product component? Ecommerce: 4) In passwordemail.ftl there are few labels from ECommerce -> Since the email password should not only be an ecommerce feature this should be moved to Common. Should we try to resolve these dependences and then merge to security in the framework? -Bruno 2009/12/11 Scott Gray : I guess the first thing we need to understand is why it exists in the first place? I'm assuming it has some dependencies on application components that prevent it from being in the framework (even if perhaps some of the logic could be moved). Regards Scott HotWax Media http://www.hotwaxmedia.com On 11/12/2009, at 11:41 PM, Bruno Busco wrote: Hi, the securityext component is actually located in the application folder. It implements the sending of the password remainder, password updated services, permission groups etc. that we want available in the framework-only release also. Do we agree to change it to move it over there? At least the labels used from ecommerce needs to be changed and some store dependencies also. -Bruno smime.p7s Description: S/MIME cryptographic signature
Re: Moving securityext to the framework
UserLogin has a partyId field extended in Party application. This is certainly something that is widely used (so convenient) and should be taken with care. Jacques From: "Bruno Busco" Hi David, devs, I searched the SVN logs to look for a reason for those general purpose login and password stuff being in the application and not in the framework. I found they are there since the incubator time. What I think should be done is to merge the securityext to the security component in the framework. I would like to try to do it, but please, if you see something blocking this or something that should be done first, or even a reason for not to do this, please advice. Thank you, -Bruno 2009/12/26 Bruno Busco : Scott, from a securityext code browsing I see that there is a dependence from Party, Product and Ecommerce. Party: 1) The UserDemoData.xml file creates several Party, Person, PartyRole, PartyContactMech entities -> Could be moved to Party? 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in the updatePassword service. This is to be sure that an admin can always update a password, even not knowing the current password. -> An admin permission should be checked here. Product: 3) In the LoginEvents.java the emailPassword method is written to be used for a ProductStore. The password email should be a core feature not used for ProductStores only. -> Could we split this method in a framework one and an higher level part (dedicated for a ProductStore) implemented in the Product component? Ecommerce: 4) In passwordemail.ftl there are few labels from ECommerce -> Since the email password should not only be an ecommerce feature this should be moved to Common. Should we try to resolve these dependences and then merge to security in the framework? -Bruno 2009/12/11 Scott Gray : I guess the first thing we need to understand is why it exists in the first place? I'm assuming it has some dependencies on application components that prevent it from being in the framework (even if perhaps some of the logic could be moved). Regards Scott HotWax Media http://www.hotwaxmedia.com On 11/12/2009, at 11:41 PM, Bruno Busco wrote: Hi, the securityext component is actually located in the application folder. It implements the sending of the password remainder, password updated services, permission groups etc. that we want available in the framework-only release also. Do we agree to change it to move it over there? At least the labels used from ecommerce needs to be changed and some store dependencies also. -Bruno
Re: Moving securityext to the framework
Hi David, devs, I searched the SVN logs to look for a reason for those general purpose login and password stuff being in the application and not in the framework. I found they are there since the incubator time. What I think should be done is to merge the securityext to the security component in the framework. I would like to try to do it, but please, if you see something blocking this or something that should be done first, or even a reason for not to do this, please advice. Thank you, -Bruno 2009/12/26 Bruno Busco : > Scott, > from a securityext code browsing I see that there is a dependence from > Party, Product and Ecommerce. > > Party: > 1) The UserDemoData.xml file creates several Party, Person, PartyRole, > PartyContactMech entities > -> Could be moved to Party? > 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in > the updatePassword service. This is to be sure that an admin can > always update a password, even not knowing the current password. > -> An admin permission should be checked here. > > Product: > 3) In the LoginEvents.java the emailPassword method is written to be > used for a ProductStore. The password email should be a core feature > not used for ProductStores only. > -> Could we split this method in a framework one and an higher > level part (dedicated for a ProductStore) implemented in the Product > component? > > Ecommerce: > 4) In passwordemail.ftl there are few labels from ECommerce -> Since > the email password should not only be an ecommerce feature this should > be moved to Common. > > Should we try to resolve these dependences and then merge to security > in the framework? > > -Bruno > > > 2009/12/11 Scott Gray : >> I guess the first thing we need to understand is why it exists in the first >> place? I'm assuming it has some dependencies on application components that >> prevent it from being in the framework (even if perhaps some of the logic >> could be moved). >> >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 11/12/2009, at 11:41 PM, Bruno Busco wrote: >> >>> Hi, >>> the securityext component is actually located in the application folder. >>> It implements the sending of the password remainder, password updated >>> services, permission groups etc. that we want available in the >>> framework-only release also. >>> >>> Do we agree to change it to move it over there? >>> At least the labels used from ecommerce needs to be changed and some >>> store dependencies also. >>> >>> -Bruno >> >> >
Re: Moving securityext to the framework
Scott, from a securityext code browsing I see that there is a dependence from Party, Product and Ecommerce. Party: 1) The UserDemoData.xml file creates several Party, Person, PartyRole, PartyContactMech entities -> Could be moved to Party? 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in the updatePassword service. This is to be sure that an admin can always update a password, even not knowing the current password. -> An admin permission should be checked here. Product: 3) In the LoginEvents.java the emailPassword method is written to be used for a ProductStore. The password email should be a core feature not used for ProductStores only. -> Could we split this method in a framework one and an higher level part (dedicated for a ProductStore) implemented in the Product component? Ecommerce: 4) In passwordemail.ftl there are few labels from ECommerce -> Since the email password should not only be an ecommerce feature this should be moved to Common. Should we try to resolve these dependences and then merge to security in the framework? -Bruno 2009/12/11 Scott Gray : > I guess the first thing we need to understand is why it exists in the first > place? I'm assuming it has some dependencies on application components that > prevent it from being in the framework (even if perhaps some of the logic > could be moved). > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 11/12/2009, at 11:41 PM, Bruno Busco wrote: > >> Hi, >> the securityext component is actually located in the application folder. >> It implements the sending of the password remainder, password updated >> services, permission groups etc. that we want available in the >> framework-only release also. >> >> Do we agree to change it to move it over there? >> At least the labels used from ecommerce needs to be changed and some >> store dependencies also. >> >> -Bruno > >
Re: Moving securityext to the framework
I guess the first thing we need to understand is why it exists in the first place? I'm assuming it has some dependencies on application components that prevent it from being in the framework (even if perhaps some of the logic could be moved). Regards Scott HotWax Media http://www.hotwaxmedia.com On 11/12/2009, at 11:41 PM, Bruno Busco wrote: Hi, the securityext component is actually located in the application folder. It implements the sending of the password remainder, password updated services, permission groups etc. that we want available in the framework-only release also. Do we agree to change it to move it over there? At least the labels used from ecommerce needs to be changed and some store dependencies also. -Bruno smime.p7s Description: S/MIME cryptographic signature
