date:20180821

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Jacques Le Roux

Hi Jinghai,

You maybe read it already, what did redislabs very recently might be affecting
you

https://redislabs.com/community/commons-clause/

Jacques

Le 15/08/2018 à 14:37, Shi Jinghai a écrit :

Dear Jacques,

On how to store the Tokens, as a token is a key, value is the UserLogin entity
and/or other info, a key-value db, Redis[1] is a good choice. Redis is no.7 in
db ranking in Aug 2018[2], becomes more and more popular. Goldman Sachs
invested Redis team in last year[3]. It's common view now in China that Redis
is better than any others including Gemfire of Pivotal, the railway ticket
system of China replaced its 3 Gemfire clusters with 3 Redis clusters last year
and then there are much less complains on how difficulties to buy spring
festival tickets.

Mr. Dai Haipeng contributed a Redis component in Jira[4].

[1] https://redis.io/
[2] https://db-engines.com/en/ranking
[3]
https://redislabs.com/press/redis-labs-secures-44-million-funding-led-goldman-sachs-private-capital-investing-strengthen-database-leadership/
[4] https://issues.apache.org/jira/browse/OFBIZ-9829

BTW, I'll try to review the patches.

Kind Regards,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月15日 15:09
收件人: dev@ofbiz.apache.org
主题: OFBIZ-10307: Navigate from a domain to another with automated signed in
authentication

Hi,

Some time ago I created https://issues.apache.org/jira/browse/OFBIZ-10307.

I asked for reviews but only Taher answered and he asked to know the goal of
this new feature.

It was actually developed for a client who needed to get from one OFBiz
instance on a server (on a domain) to another OFBiz instance on another
server (on another domain) without having to sign up between the 2 while
keeping things secure.

There could be many reasons why you want to split OFBiz application on servers.
In their case it was for performance issues.

The technology used is as secure as possible. Like OAuth 2.0 it uses a token
but it does not need a middle authorization server (think to two-factor
authentication) because it's only for OFBiz instances of the same version.

To commit this work we need 1st to agree an commit the work done by Deepak at OFBIZ-9833
"Token Based Authentication" that I use in my last patch.

For me there is only one question outstanding: how to store the Token secret.
But this should not prevent us to commit Deepak's work.

It's now a long time (9 months) since I started this work. And my last patch is
ready for a month.

I crossed several issues which are now all resolved. So please review and
answer to this thread.

Without negative comments well argumented I'll commit both OFBIZ-9833 and
OFBIZ-10307 in a week. You can always test and review later, we use RTC.

Also a veto on a commit is always possible... Of course, as ever, a good
consensus is preferred.

Let me know if you need more information about the goal. For the technical
details I think I already provided them the in OFBIZ-10307.

Jacques

Re: Inventory Allocation Planning

2018-08-21 Thread deepak nigam

Here is the JIRA ticket for the 'reserverAfterDate' feature.
https://issues.apache.org/jira/browse/OFBIZ-10534

I have uploaded the patch and screenshots of the feature.

Thanks & Regards
--
Deepak Nigam
HotWax Systems

On Mon, Aug 20, 2018 at 2:31 PM deepak nigam 
wrote:

> Here is the JIRA ticket for the same:
> https://issues.apache.org/jira/browse/OFBIZ-10518
>
> I will provide the updated patch soon.
>
> On Sat, Aug 18, 2018 at 5:51 PM Pierre Smits 
> wrote:
>
>> Without a JIRA ticket providing the necessary business and use cases, et
>> al, it is difficult to address this topic.
>>
>> One thing to keep in mind though, is that the (ultimate) gatekeeper
>> regarding fulfilment of orders is the warehouse manager.
>>
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> Apache Trafodion , Vice President
>> Apache Directory , PMC Member
>> Apache Incubator , committer
>> *Apache OFBiz , contributor (without
>> privileges)
>> since 2008*
>> Apache Steve , committer
>>
>> On Sat, Aug 18, 2018 at 9:01 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> > Hi Deepak,
>> >
>> > Will you later provide a patch in a Jira? It's easier for review.
>> >
>> > Jacques
>> >
>> >
>> >
>> > Le 17/08/2018 à 07:42, deepak nigam a écrit :
>> >
>> >> I have started some implementation regarding this. Here is the link for
>> >> the
>> >> reference,
>> >>
>> >> https://github.com/Deepak27021990/ofbiz-framework/tree/
>> >> sales-allocation-plan
>> >>
>> >> Thanks & Regards
>> >> --
>> >> Deepak Nigam
>> >>
>> >> On Thu, Aug 16, 2018 at 5:39 PM deepak nigam <
>> deepak.nigam1...@gmail.com>
>> >> wrote:
>> >>
>> >> Moving thread to the dev mailing list.
>> >>>
>> >>> On Thu, Aug 16, 2018 at 3:33 PM Jacques Le Roux <
>> >>> jacques.le.r...@les7arts.com> wrote:
>> >>>
>> >>> Hi Deepak,
>> 
>>  Interesting proposition, this should be discussed in dev ML
>> 
>>  Thanks
>> 
>>  Jacques
>> 
>> 
>>  Le 16/08/2018 à 11:28, deepak nigam a écrit :
>> 
>> > While creating orders from the backend, we have the option to set
>> > parameters like 'Ship After Date' and 'Ship Before Date' to manage
>> the
>> > fulfilment cycle more efficiently. Inventory gets reserved for the
>> >
>>  product
>> 
>> > based on a FIFO basis. Sometimes the fulfilment time for the order
>> is
>> >
>>  high
>> 
>> > and inventory unnecessarily gets locked for some time period.
>> >
>> > We can introduce a new parameter (at order item level) 'Reserve
>> After
>> >
>>  Date'
>> 
>> > which will indicate the date only after which reservation can
>> happen.
>> > In
>> > this way, we can manage the stock availability more efficiently.
>> >
>> > On Mon, Aug 13, 2018 at 10:35 AM deepak nigam <
>> >
>>  deepak.nigam1...@gmail.com>
>> 
>> > wrote:
>> >
>> > Thanks, James.
>> >>
>> >> Here is the JIRA ticket
>> >>  for the same.
>> >>
>> > Soon I
>> 
>> > will share detailed design notes here and in the ticker also.
>> >>
>> >>
>> >> Thanks & Regards
>> >> --
>> >> Deepak Nigam
>> >>
>> >> On Mon, Aug 13, 2018 at 2:17 AM  wrote:
>> >>
>> >> Deepak - I did not see it in OFbiz but I did in Opentaps.  I can
>> send
>> >>> you a video of the functionality
>> >>>
>> >>>  Original Message 
>> >>> Subject: Re: Inventory Allocation Planning
>> >>> From: deepak nigam 
>> >>> Date: Thu, August 09, 2018 2:24 am
>> >>> To: u...@ofbiz.apache.org, ja...@productive1.com
>> >>>
>> >>> Hi James,
>> >>>
>> >>> Did you get a chance to confirm it in OFBiz?
>> >>>
>> >>>
>> >>> @All,
>> >>> As far as I came to know, the feature to allocate the inventory
>> (not
>> >>> actual reservation at this point) is not available OOTB. We can
>> think
>> >>> about the idea of its implementation.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Thanks & Regards
>> >>> --
>> >>> Deepak Nigam
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Sun, Aug 5, 2018 at 10:14 PM  wrote:
>> >>>
>> >>> This will only allocate the current inventory.  I see it in
>> >>>opentaps...let me confirm in Ofbiz.
>> >>>
>> >>> Original Message 
>> >>>Subject: Re: Inventory Allocation Planning
>> >>>From: deepak nigam 
>> >>>Date: Fri, August 03, 2018 12:40 am
>> >>>To: u...@ofbiz.apache.org
>> >>>
>> >>>Thanks, James.
>> >>>
>> >>>Will this method honour the upcoming supply also? I am more
>> >>>
>> >> interested
>> 
>> >in a
>> >>>supply allocation plan by using which I can allocate the
>> available

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Jacques Le Roux


Hi Nicolas,

One week is OK with me. You will see, it's plain simple now.

Thanks

Jacques


Le 21/08/2018 à 14:11, Nicolas Malin a écrit :

Hello Jacques, I will take the time to review it, please give me one week :)

Nicolas


On 21/08/2018 13:48, Jacques Le Roux wrote:

Le 21/08/2018 à 12:20, Michael Brohl a écrit :
The history of this issue clearly shows that it is necessary to have a close look at this work. So please wait until committers have had enough 
time to review the updated/corrected patches. 

OK, how much time do you estimate for that?

Note that the last change, after Scott's review is very simple, so I hope I'll 
not have to wait for months for other reviews.

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Nicolas Malin


Hello Jacques, I will take the time to review it, please give me one week :)

Nicolas


On 21/08/2018 13:48, Jacques Le Roux wrote:

Le 21/08/2018 à 12:20, Michael Brohl a écrit :
The history of this issue clearly shows that it is necessary to have 
a close look at this work. So please wait until committers have had 
enough time to review the updated/corrected patches. 

OK, how much time do you estimate for that?

Note that the last change, after Scott's review is very simple, so I 
hope I'll not have to wait for months for other reviews.


Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Michael Brohl

I mean the concerns which already were raised, e.g. by Taher and Scott, 
who made you rethink your work you were going to commit.


You cannot simply ignore them and say you will commit your work.

The history of this issue clearly shows that it is necessary to have a 
close look at this work. So please wait until committers have had enough 
time to review the updated/corrected patches.


Thanks,

Michael


Am 21.08.18 um 11:40 schrieb Jacques Le Roux:

Le 21/08/2018 à 10:41, Michael Brohl a écrit :

Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of 
this work shows. This work is now ready and good, so I'll soon 
commit it.


So you want to ignore raised concerns and commit despite of them?



What are your raised concerns? Are they technically sustained?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Jacques Le Roux

Le 21/08/2018 à 11:10, Gil Portenseigne a écrit :

I've not analysed the issue in details, but an in-middle solution should
be to remove the problematic links from trunk,
That's what I thought initially, and created OFBIZ-9241 for that. Then I thought we could simply hide them when the ecommerce component is not used,
rather than removing them. Because they are useful, but I have not a strong opinion about that.

It seems Deepak and Michael have other ideas, let's see what will come from
them. I mean in term of patches for review...

Jacques

and fill a new Jira for
implementing it in the better way :).
Gil

Le mardi 21 août 2018 à 10:10:03 (+0200), Jacques Le Roux a écrit :

OK, that your and Michael's opinions. So you prefer NPEs in code than hiding
them when necessary?

What others think?

Jacques

Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :

Again, hiding is not a solution and is correcting an error with another
error.

-1

On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux
wrote:

See my answer in the Jira, we can't tolerate NPEs, they are already there
for too long

Being smart is cool, being smart and clean is better ;)

Jacques

Le 21/08/2018 à 08:57, Michael Brohl a écrit :

We should neither simply remove those links nor should we have anything

hard coded.

Let's look for a smarter solution. No need to hurry, better take some

time to implement something sustainable.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 21.08.18 um 07:00 schrieb Jacques Le Roux:

Of course, but I like to be able to get from the backend to the

frontend when it's possible.

I don't see any troubles keeping them once it's handled that way, but

theoretical ones .

Of course if the community prefers to remove them it's far easier and

was what I wanted to do initially before having this idea of hiding links

Jacques

Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :

Simple, don't put any logic that points outwards from the framework.

That

is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:

Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :

Makes sense. However, i note reading in the JIRA that "we can simply

hide

the button when the ecommerce component is not present". That sounds

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.

Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques

On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:

Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework

only

and

the
framework+plugins

I must add:

* since the old is often no longer supported and a release of

it is

always available (today R13) for users. I think removing the old

demo is

maybe
not a big deal.
* I found several cases where people, new to OFBiz, considered

OFBiz

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Jacques Le Roux


Le 21/08/2018 à 10:41, Michael Brohl a écrit :

Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of this work 
shows. This work is now ready and good, so I'll soon commit it.


So you want to ignore raised concerns and commit despite of them?



What are your raised concerns? Are they technically sustained?

Jacques

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Gil Portenseigne

I've not analysed the issue in details, but an in-middle solution should
be to remove the problematic links from trunk, and fill a new Jira for
implementing it in the better way :).
Gil

Le mardi 21 août 2018 à 10:10:03 (+0200), Jacques Le Roux a écrit :
> OK, that your and Michael's opinions. So you prefer NPEs in code than hiding 
> them when necessary?
> 
> What others think?
> 
> Jacques
> 
> 
> Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :
> > Again, hiding is not a solution and is correcting an error with another
> > error.
> > 
> > -1
> > 
> > On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux 
> > 
> > wrote:
> > 
> > > See my answer in the Jira, we can't tolerate NPEs, they are already there
> > > for too long
> > > 
> > > Being smart is cool, being smart and clean is better ;)
> > > 
> > > Jacques
> > > 
> > > 
> > > Le 21/08/2018 à 08:57, Michael Brohl a écrit :
> > > > We should neither simply remove those links nor should we have anything
> > > hard coded.
> > > > Let's look for a smarter solution. No need to hurry, better take some
> > > time to implement something sustainable.
> > > > Regards,
> > > > 
> > > > Michael Brohl
> > > > ecomify GmbH
> > > > www.ecomify.de
> > > > 
> > > > 
> > > > Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
> > > > > Of course, but I like to be able to get from the backend to the
> > > frontend when it's possible.
> > > > > I don't see any troubles keeping them once it's handled that way, but
> > > theoretical ones .
> > > > > Of course if the community prefers to remove them it's far easier and
> > > was what I wanted to do initially before having this idea of hiding links
> > > > > Jacques
> > > > > 
> > > > > 
> > > > > Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
> > > > > > Simple, don't put any logic that points outwards from the framework.
> > > That
> > > > > > is sort of why we split repositories in the first place.
> > > > > > 
> > > > > > On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <
> > > jacques.le.r...@les7arts.com>
> > > > > > wrote:
> > > > > > 
> > > > > > > Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
> > > > > > > > Makes sense. However, i note reading in the JIRA that "we can 
> > > > > > > > simply
> > > hide
> > > > > > > > the button when the ecommerce component is not present". That 
> > > > > > > > sounds
> > > like
> > > > > > > > logic that points outwards which is a bad design IMHO.
> > > > > > > I could not find a better way yet, I'm all ears for ideas.
> > > > > > > 
> > > > > > > > Anyway, I think it is a reasonable step to take. +1
> > > > > > > I attached a patch for today at OFBIZ-9241
> > > > > > > 
> > > > > > > Jacques
> > > > > > > 
> > > > > > > > On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
> > > > > > > jacques.le.r...@les7arts.com>
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > The proposition is in the title.
> > > > > > > > > 
> > > > > > > > > With the changes I'm introducing with OFBIZ-9241 there will 
> > > > > > > > > few
> > > > > > > > > differences in UI (and presence of js files) between the 
> > > > > > > > > framework
> > > only
> > > > > > > and
> > > > > > > > > the
> > > > > > > > > framework+plugins
> > > > > > > > > 
> > > > > > > > > I must add:
> > > > > > > > > 
> > > > > > > > >  * since the old is often no longer supported and a 
> > > > > > > > > release of
> > > it is
> > > > > > > > > always available (today R13) for users. I think removing the 
> > > > > > > > > old
> > > demo is
> > > > > > > > > maybe
> > > > > > > > >not a big deal.
> > > > > > > > >  * I found several cases where people, new to OFBiz, 
> > > > > > > > > considered
> > > OFBiz
> > > > > > > as
> > > > > > > > > what we call the framework, and were considering the plugins 
> > > > > > > > > as
> > > > > > > optional.
> > > > > > > > > What do you think?
> > > > > > > > > 
> > > > > > > > > Jacques
> > > > > > > > > 
> > > > > > > > > 
> > > > 
> > > 
>

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Taher Alkhateeb

I did not say I prefer NPEs, don't put words in my mouth.

On Tue, Aug 21, 2018, 11:09 AM Jacques Le Roux 
wrote:

> OK, that your and Michael's opinions. So you prefer NPEs in code than
> hiding them when necessary?
>
> What others think?
>
> Jacques
>
>
> Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :
> > Again, hiding is not a solution and is correcting an error with another
> > error.
> >
> > -1
> >
> > On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> See my answer in the Jira, we can't tolerate NPEs, they are already
> there
> >> for too long
> >>
> >> Being smart is cool, being smart and clean is better ;)
> >>
> >> Jacques
> >>
> >>
> >> Le 21/08/2018 à 08:57, Michael Brohl a écrit :
> >>> We should neither simply remove those links nor should we have anything
> >> hard coded.
> >>> Let's look for a smarter solution. No need to hurry, better take some
> >> time to implement something sustainable.
> >>> Regards,
> >>>
> >>> Michael Brohl
> >>> ecomify GmbH
> >>> www.ecomify.de
> >>>
> >>>
> >>> Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
>  Of course, but I like to be able to get from the backend to the
> >> frontend when it's possible.
>  I don't see any troubles keeping them once it's handled that way, but
> >> theoretical ones .
>  Of course if the community prefers to remove them it's far easier and
> >> was what I wanted to do initially before having this idea of hiding
> links
>  Jacques
> 
> 
>  Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
> > Simple, don't put any logic that points outwards from the framework.
> >> That
> > is sort of why we split repositories in the first place.
> >
> > On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
> >>> Makes sense. However, i note reading in the JIRA that "we can
> simply
> >> hide
> >>> the button when the ecommerce component is not present". That
> sounds
> >> like
> >>> logic that points outwards which is a bad design IMHO.
> >> I could not find a better way yet, I'm all ears for ideas.
> >>
> >>> Anyway, I think it is a reasonable step to take. +1
> >> I attached a patch for today at OFBIZ-9241
> >>
> >> Jacques
> >>
> >>> On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com>
> >>> wrote:
> >>>
>  Hi,
> 
>  The proposition is in the title.
> 
>  With the changes I'm introducing with OFBIZ-9241 there will few
>  differences in UI (and presence of js files) between the framework
> >> only
> >> and
>  the
>  framework+plugins
> 
>  I must add:
> 
>   * since the old is often no longer supported and a release of
> >> it is
>  always available (today R13) for users. I think removing the old
> >> demo is
>  maybe
> not a big deal.
>   * I found several cases where people, new to OFBiz,
> considered
> >> OFBiz
> >> as
>  what we call the framework, and were considering the plugins as
> >> optional.
>  What do you think?
> 
>  Jacques
> 
> 
> >>>
> >>
>
>

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Michael Brohl


Jacques,

Am 21.08.18 um 10:27 schrieb Jacques Le Roux:

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of this 
work shows. This work is now ready and good, so I'll soon commit it.


So you want to ignore raised concerns and commit despite of them?




smime.p7s
Description: S/MIME Cryptographic Signature

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Jacques Le Roux

You are totaly right on this Michael

I do treat the trunk as much care as possible as the evolution of this work
shows. This work is now ready and good, so I'll soon commit it.

Jacques

Le 21/08/2018 à 10:13, Michael Brohl a écrit :

Jacques,

just a remark on this:

> Remember this is only trunk and will not be released before at least 1 year
and most possibly 2, you have plenty of time.

Even this is trunk and can be unstable, we should treat trunk with the same care as we do with release branches. trunk is not meant to put
everything in and see if it works or someone finds a bug. We all know that this ist the root cause for some problematic code we have to deal with.

And we should not forget that new users also check out trunk to evaluate OFBiz,
so it is important to have it as stable and bug free as possible.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

Am 20.08.18 um 09:28 schrieb Jacques Le Roux:

Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :

Wow, so after having a long, long email (as usual) talking about how
good the work is and you deployed for a client (my god!), now you
reverted because of a fundamental flaw pointed out by Scott.

I did not revert, it was not committed. I updated my patch and it was really a
small change.
Initially I already planned to not use the client side to grab the loginId with OFBIZ-10206. But forgot about it because I stumbled upon many other
issues since.

This work was challenging at many levels, believe me. I'll not drop it without
really good arguments!

And now you want to apply lazy consensus despite my objections and the
obvious flaw which you acknowledged. This makes me skeptical of the
entire approach and the quality of the code in question. I would
prefer if you halt all work and study what you're doing instead of
falling into more mistakes.

Again, please give me good *technical* arguments. My work works and is safe,
prove the contrary.

I'm also distressed with your phrase "Without negative comments well
argumented I'll commit both". In other words if you can't convince me
i'm pushing this code, why, because I want to. That's not how
community works.

Keep calm, you can still prevent me to commit if you give me good argument as
Scoot did.
And if you can't find them now you will still be able to veto if you find some
later.
And again as explained at https://www.apache.org/foundation/voting.html#Veto
you need arguments:

/To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a
security exposure, negatively affects performance, //etc.//). A veto without
a justification is invalid and has no weight./

Remember this is only trunk and will not be released before at least 1 year and
most possibly 2, you have plenty of time.

I'm all ears

Jacques

On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
wrote:

ôOps missed some words...

Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and
https://jwt.io/ to

allow an user to connect to another OFBiz instance (using same version than
source) on another server (target) on another domain w/o signing in.

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Michael Brohl


Jacques,

just a remark on this:


> Remember this is only trunk and will not be released before at least 
1 year and most possibly 2, you have plenty of time.


Even this is trunk and can be unstable, we should treat trunk with the 
same care as we do with release branches. trunk is not meant to put 
everything in and see if it works or someone finds a bug. We all know 
that this ist the root cause for some problematic code we have to deal with.


And we should not forget that new users also check out trunk to evaluate 
OFBiz, so it is important to have it as stable and bug free as possible.


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 20.08.18 um 09:28 schrieb Jacques Le Roux:

Le 19/08/2018 à 20:25, Taher Alkhateeb a écrit :

Wow, so after having a long, long email (as usual) talking about how
good the work is and you deployed for a client (my god!), now you
reverted because of a fundamental flaw pointed out by Scott.
I did not revert, it was not committed. I updated my patch and it was 
really a small change.
Initially I already planned to not use the client side to grab the 
loginId with OFBIZ-10206. But forgot about it because I stumbled upon 
many other issues since.
This work was challenging at many levels, believe me. I'll not drop it 
without really good arguments!



And now you want to apply lazy consensus despite my objections and the
obvious flaw which you acknowledged. This makes me skeptical of the
entire approach and the quality of the code in question. I would
prefer if you halt all work and study what you're doing instead of
falling into more mistakes.
Again, please give me good *technical* arguments. My work works and is 
safe, prove the contrary.



I'm also distressed with your phrase "Without negative comments well
argumented I'll commit both". In other words if you can't convince me
i'm pushing this code, why, because I want to. That's not how
community works.
Keep calm, you can still prevent me to commit if  you give me good 
argument as Scoot did.
And if you can't find them now you will still be able to veto if you 
find some later.
And again as explained at 
https://www.apache.org/foundation/voting.html#Veto you need arguments:


   /To prevent vetos from being used capriciously, they must be 
accompanied by a technical justification showing why the change is bad 
(opens a
   security exposure, negatively affects performance, //etc.//). A 
veto without a justification is invalid and has no weight./


Remember this is only trunk and will not be released before at least 1 
year and most possibly 2, you have plenty of time.


I'm all ears

Jacques


On Sun, Aug 19, 2018 at 3:29 PM Jacques Le Roux
 wrote:

ôOps missed some words...

Le 19/08/2018 à 12:33, Jacques Le Roux a écrit :
I simply send a JWT token: 
https://en.wikipedia.org/wiki/JSON_Web_Token and https://jwt.io/ to
allow an user to connect to another OFBiz instance (using same 
version than source) on another server (target) on another domain 
w/o signing in.


Jacques









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Jacques Le Roux


OK, that your and Michael's opinions. So you prefer NPEs in code than hiding 
them when necessary?

What others think?

Jacques


Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :

Again, hiding is not a solution and is correcting an error with another
error.

-1

On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux 
wrote:


See my answer in the Jira, we can't tolerate NPEs, they are already there
for too long

Being smart is cool, being smart and clean is better ;)

Jacques


Le 21/08/2018 à 08:57, Michael Brohl a écrit :

We should neither simply remove those links nor should we have anything

hard coded.

Let's look for a smarter solution. No need to hurry, better take some

time to implement something sustainable.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.08.18 um 07:00 schrieb Jacques Le Roux:

Of course, but I like to be able to get from the backend to the

frontend when it's possible.

I don't see any troubles keeping them once it's handled that way, but

theoretical ones .

Of course if the community prefers to remove them it's far easier and

was what I wanted to do initially before having this idea of hiding links

Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :

Simple, don't put any logic that points outwards from the framework.

That

is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :

Makes sense. However, i note reading in the JIRA that "we can simply

hide

the button when the ecommerce component is not present". That sounds

like

logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework

only

and

the
framework+plugins

I must add:

 * since the old is often no longer supported and a release of

it is

always available (today R13) for users. I think removing the old

demo is

maybe
   not a big deal.
 * I found several cases where people, new to OFBiz, considered

OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Taher Alkhateeb

Again, hiding is not a solution and is correcting an error with another
error.

-1

On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux 
wrote:

> See my answer in the Jira, we can't tolerate NPEs, they are already there
> for too long
>
> Being smart is cool, being smart and clean is better ;)
>
> Jacques
>
>
> Le 21/08/2018 à 08:57, Michael Brohl a écrit :
> > We should neither simply remove those links nor should we have anything
> hard coded.
> >
> > Let's look for a smarter solution. No need to hurry, better take some
> time to implement something sustainable.
> >
> > Regards,
> >
> > Michael Brohl
> > ecomify GmbH
> > www.ecomify.de
> >
> >
> > Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
> >> Of course, but I like to be able to get from the backend to the
> frontend when it's possible.
> >> I don't see any troubles keeping them once it's handled that way, but
> theoretical ones .
> >>
> >> Of course if the community prefers to remove them it's far easier and
> was what I wanted to do initially before having this idea of hiding links
> >>
> >> Jacques
> >>
> >>
> >> Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
> >>> Simple, don't put any logic that points outwards from the framework.
> That
> >>> is sort of why we split repositories in the first place.
> >>>
> >>> On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com>
> >>> wrote:
> >>>
>  Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
> > Makes sense. However, i note reading in the JIRA that "we can simply
> hide
> > the button when the ecommerce component is not present". That sounds
> like
> > logic that points outwards which is a bad design IMHO.
>  I could not find a better way yet, I'm all ears for ideas.
> 
> > Anyway, I think it is a reasonable step to take. +1
>  I attached a patch for today at OFBIZ-9241
> 
>  Jacques
> 
> > On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
>  jacques.le.r...@les7arts.com>
> > wrote:
> >
> >> Hi,
> >>
> >> The proposition is in the title.
> >>
> >> With the changes I'm introducing with OFBIZ-9241 there will few
> >> differences in UI (and presence of js files) between the framework
> only
>  and
> >> the
> >> framework+plugins
> >>
> >> I must add:
> >>
> >> * since the old is often no longer supported and a release of
> it is
> >> always available (today R13) for users. I think removing the old
> demo is
> >> maybe
> >>   not a big deal.
> >> * I found several cases where people, new to OFBiz, considered
> OFBiz
>  as
> >> what we call the framework, and were considering the plugins as
>  optional.
> >> What do you think?
> >>
> >> Jacques
> >>
> >>
> 
> >>
> >
> >
>
>

Re: [PROPOSITION] Demos: replace old by trunk framework only

2018-08-21 Thread Jacques Le Roux


See my answer in the Jira, we can't tolerate NPEs, they are already there for 
too long

Being smart is cool, being smart and clean is better ;)

Jacques


Le 21/08/2018 à 08:57, Michael Brohl a écrit :

We should neither simply remove those links nor should we have anything hard 
coded.

Let's look for a smarter solution. No need to hurry, better take some time to 
implement something sustainable.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 21.08.18 um 07:00 schrieb Jacques Le Roux:

Of course, but I like to be able to get from the backend to the frontend when 
it's possible.
I don't see any troubles keeping them once it's handled that way, but 
theoretical ones .

Of course if the community prefers to remove them it's far easier and was what 
I wanted to do initially before having this idea of hiding links

Jacques


Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :

Simple, don't put any logic that points outwards from the framework. That
is sort of why we split repositories in the first place.

On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux 
wrote:


Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :

Makes sense. However, i note reading in the JIRA that "we can simply hide
the button when the ecommerce component is not present". That sounds like
logic that points outwards which is a bad design IMHO.

I could not find a better way yet, I'm all ears for ideas.


Anyway, I think it is a reasonable step to take. +1

I attached a patch for today at OFBIZ-9241

Jacques


On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Hi,

The proposition is in the title.

With the changes I'm introducing with OFBIZ-9241 there will few
differences in UI (and presence of js files) between the framework only

and

the
framework+plugins

I must add:

    * since the old is often no longer supported and a release of it is
always available (today R13) for users. I think removing the old demo is
maybe
  not a big deal.
    * I found several cases where people, new to OFBiz, considered OFBiz

as

what we call the framework, and were considering the plugins as

optional.

What do you think?

Jacques

Re: OFBIZ-10307: Navigate from a domain to another with automated signed in authentication

2018-08-21 Thread Michael Brohl

Hi Shi,

what do you mean when you say you are going to release the plugin? Where
will this take place?

Regards,

Michael

Am 19.08.18 um 22:00 schrieb Shi Jinghai:

Thanks Jacques!

If so, I'll release a CAS plugin to make OFBiz offer OAuth2 alliance next week.
I have cas 4.2.x version running in production environment, I'll upgrade it to
cas 5.2.x and then release it.

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月19日 18:34
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in
authentication

Hi Jinghai,

Actually I did not pick auth0 (not to be confused with
https://en.wikipedia.org/wiki/OAuth) nor https://oauth.net/2/ because those
need a central
Identify server (as is the SAML protocol).

I simply send a JWT token: https://en.wikipedia.org/wiki/JSON_Web_Token and
https://jwt.io/ to

Please refer to OFBIZ-10307 "Navigate from a domain to another with automated signed
in authentication"

Thanks for your interest.

Jacques

Le 17/08/2018 à 09:02, Shi Jinghai a écrit :

Hi Jacques,

OK, I think the redis topic is jumped to next step.

I have read the patches carelly, as a fan of Apereo CAS[1], I wonder why choose
auth0[2] rather than CAS. And is the implement OAuth2 alliance?

[1] https://github.com/apereo/cas
[2] https://auth0.com/

Kind Regards,

Shi Jinghai

-邮件原件-
发件人: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
发送时间: 2018年8月16日 2:08
收件人: dev@ofbiz.apache.org
主题: Re: OFBIZ-10307: Navigate from a domain to another with automated signed in
authentication

Hi Jinghai,

The problem with the token master secret key is to guarantee its secrecy at max.

We already discussed different solutions at https://s.apache.org/7yyR and
https://s.apache.org/IBDM

How is Redis more secure than Postgres for storing values?

Thanks