Re: Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Yes, I can elaborate a better explanation. I would like to be sure that 
there is no historical mistake with the minified files before digging 
further.


I'll open a Jira and make an example to explain my proposal.

Regards,

Julien.


Le 27/08/2018 à 15:00, Taher Alkhateeb a écrit :

Can you elaborate on how you want to design this feature? Are you
going to minify the existing file or generate a new one. If you
generate a new one how will you update the screens to refer to the
minified version? Some elaboration on the design might help to make a
better decision here perhaps?
On Mon, Aug 27, 2018 at 3:20 PM Julien NICOLAS
 wrote:

Yes ! This is exactly what I have in mind ;)

Using this feature in production using Gulp, It's a pain when you have
to debbug in minified version.

Julien.


Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :

Hello Julien,

Julien NICOLAS  writes:


I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or
compilation...) less to css and minify and gzip css files.

What do you think if I try to set it in trunk ? I saw that a minifier
was already implemented in the past but was also removed. Is there any
technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.

Re: Gradle, Less, Css : Transpile and minify

[Taher Alkhateeb]

Can you elaborate on how you want to design this feature? Are you
going to minify the existing file or generate a new one. If you
generate a new one how will you update the screens to refer to the
minified version? Some elaboration on the design might help to make a
better decision here perhaps?
On Mon, Aug 27, 2018 at 3:20 PM Julien NICOLAS
 wrote:
>
> Yes ! This is exactly what I have in mind ;)
>
> Using this feature in production using Gulp, It's a pain when you have
> to debbug in minified version.
>
> Julien.
>
>
> Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :
> > Hello Julien,
> >
> > Julien NICOLAS  writes:
> >
> >> I would like to optimize css and less management using gradle.
> >> I saw that some gradle plugins exists for transpilation (or
> >> compilation...) less to css and minify and gzip css files.
> >>
> >> What do you think if I try to set it in trunk ? I saw that a minifier
> >> was already implemented in the past but was also removed. Is there any
> >> technical reasons to remove minifier ?
> > I think it is a good idea.  However if we do that, it will be very
> > important to have a convenient way to run OFBiz either in development
> > mode (without minification) and in production mode (with minification)
> > to ease the Javascript debugging.  Since this is a very common
> > requirement, I guess those Gradle plugins already provide such facility
> > or describe how to customize the impacted tasks.
> >
> > Thanks.
> >
>

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

[Taher Alkhateeb]

I already found problems in this code to give me pause and to show
that it is not properly studied and designed. If you want to continue
the effort, then I recommend reviewing your code thoroughly, providing
a clear testing mechanism (especially the web scripts), and ask for
reviews and tests.
On Sun, Aug 26, 2018 at 12:33 PM Jacques Le Roux
 wrote:
>
> Hi Taher,
>
> Thanks for your review, much appreciated.
>
>
> Le 22/08/2018 à 18:42, Taher Alkhateeb a écrit :
> > I reviewed the code and explanation in the beginning of this thread
> > and I have the following comments:
> >
> > - First, in case of a result.containsKey(ModelService.ERROR_MESSAGE)
> > you are still returning "success". Does not make sense at all.
> You are right I should have used "error".
> I did not notice (actually forgot a last own review after much variations in 
> code) because it's an event preprocessor and no response is
> expected/handled.
> Not to bad, in case of error just an EventHandlerException was not thrown.
>
> > - Also the comments are unnecessary and do not make sense in the same code 
> > block
> You mean "// Something unexpected happened here", or ?
>
> > - The comment you wrote: "Check it's the right tenant in case username
> > and password are the same in different tenants. Not sure this is
> > really useful in the case of external server, does not hurt anyway" is
> > self-defeating. Never put in code you won't use. We have enough mess
> > in the code base.
> I must say I initially copied that from 
> ExternalLoginKeysManager::checkExternalLoginKey and adapted it to the 
> context. It's roughly the same code.
> I let it there because I was then unsure. But when you think about it, there 
> is no reason to not make this check. So I'll simply remove the comment. I
> should have put a TODO.
>
> BTW this is out of subject and I'll start a new thread about it after reading
> https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/
> The subject will be: "Should we keep the multi-tenants feature in OFBiz."
> I though think the tenants in OFBiz are still useful when you only needs 
> dozens or maybe even few hundreds tenants (begin to be a lot of DBs!).
> But I faced that with a startup which wanted to handle thousands, if not 
> millions (actually they failed), of tenants, obviously OFBiz can't do that.
>
> > - Calling LoginWorker.doBasicLogin(userLogin, request) after the
> > if/else block does not make sense. The else block guarantees falling
> > into the exception. This whole code block needs refactoring
> You are totally right, I have uploaded a new patch where I put the call of
>  LoginWorker.doBasicLogin(userLogin, request);
> in the positive part of the if and used the same block pattern than above 
> where there is a warning log then returning an error.
> I was so focused on the other parts of the mechanism, especially to secure 
> it, than I forgot to review the Java part.
> My bad, thank you again for your review.
>
> > - A testing method needs to be provided in detail. For example I'm not
> > sure how the Javascript portions will execute and when. So some
> > provision of a clear testing mechanism is necessary.
> Yep, right, I'll document all the mechanism and how to use it. Pierre even 
> proposed to make a graph in AsciiDoc, not sure I'll be able to, by I'll try.
> Actually it's only a matter of following what should be in the example 
> component, see last OFBIZ-10307-test from example.patch.
> I thought it would be enough for devs. I understand it's not, a bit of clear 
> documentation is always welcomed, and I often advocate for it.
>
> > - Finally, I'm not sure this feature is needed at all. Why not just
> > assign an LDAP server to take care of OFBiz and non-OFBiz in a single
> > sign-on environment.
> Because you don't need to have (install, maintain, etc.) a LDAP server, or 
> whatnot (CAS, Oauth2, SAML, you name it) if you use this code, it's ready 
> OOTB.
>
> >   I see too much code being written for something
> > that might not be of great value and there are other better solutions
> > out there.
> Which ones do you think about? And why they are better at doing this specific 
> feature?
>
> > Using JWT tokens might come with problems [1] that need to
> > be justified before we adopt it.
> That's very interesting, let's check, after reading 
> https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities
>
>  1. Never let the JWT header alone drive verification
>   * Not our case, we have the loginUserId ciphered in and checked. The 
> crucial point was how to send the loginUserId securely.
>  2. Know the algorithms
>   * This part is handled by JWTManager class. We have begun to discuss 
> where to store the secret key at https://s.apache.org/IiE0
>  3. Use an appropriate key size
>   * This part is handled by JWTManager class, which uses HMAC with 
> SHA-512. And that's OK reading the article Wikipedia refers to.|
> |
>
> |Jacques|
>
> >
> > 

Re: Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Yes ! This is exactly what I have in mind ;)

Using this feature in production using Gulp, It's a pain when you have 
to debbug in minified version.


Julien.


Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :

Hello Julien,

Julien NICOLAS  writes:


I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or
compilation...) less to css and minify and gzip css files.

What do you think if I try to set it in trunk ? I saw that a minifier
was already implemented in the past but was also removed. Is there any
technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.

Re: Gradle, Less, Css : Transpile and minify

[Jacques Le Roux]

Le 27/08/2018 à 12:02, Mathieu Lirzin a écrit :

Hello Julien,

Julien NICOLAS  writes:


I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or
compilation...) less to css and minify and gzip css files.

What do you think if I try to set it in trunk ? I saw that a minifier
was already implemented in the past but was also removed. Is there any
technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.


That's indeed a good idea Mathieu

Jacques

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

[Jacques Le Roux]

Hi Jinghai,

Actually you had a point speaking about auth0, in relation to the JWT secret key. I forgot that  in OFBIZ-9833 at "20/Feb/18 18:02" I considered 
https://github.com/auth0/java-jwt#using-a-keyprovider because using a KeyProvider it's an alternative solution to using a static secret key. But 
actually that's not part of my work but Deepak's at OFBIZ-9833. I now rely on OFBIZ-9833 for OFBIZ-10307.


Jacques


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

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

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: Gradle, Less, Css : Transpile and minify

[Mathieu Lirzin]

Hello Julien,

Julien NICOLAS  writes:

> I would like to optimize css and less management using gradle.
> I saw that some gradle plugins exists for transpilation (or
> compilation...) less to css and minify and gzip css files.
>
> What do you think if I try to set it in trunk ? I saw that a minifier
> was already implemented in the past but was also removed. Is there any
> technical reasons to remove minifier ?

I think it is a good idea.  However if we do that, it will be very
important to have a convenient way to run OFBiz either in development
mode (without minification) and in production mode (with minification)
to ease the Javascript debugging.  Since this is a very common
requirement, I guess those Gradle plugins already provide such facility
or describe how to customize the impacted tasks.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Editing comments in Jira

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux  writes:

> While reviewing the later I stumbled upon the "Editing comments in
> Jira" information block. It says
>
>read comments from the dev ML (Jira issues are redirected to dev
>ML).>>
>
[...]
> So should we keep this sentence,? And if not, should we keep this
> whole information block?

The JIRA summary wall [1] is a convenient way to follow OFBiz
development activity.  IMO we should remove this information block and
recommend using JIRA Web Interface instead which doesn't have this
updated comment issue.   should only be
mentioned as an alternative in “degraded” mode.

[1] https://issues.apache.org/jira/projects/OFBIZ/summary

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Gradle, Less, Css : Transpile and minify

[Deepak Dixit]

Hi Nicolas,

I think we were using yuicompressor, It was conflicting with BIRT reporting
tool.

Here are the reference ticket

https://issues.apache.org/jira/browse/OFBIZ-4849
https://issues.apache.org/jira/browse/OFBIZ-5070

I like the idea to have minified js/css files.
You can create a ticket for the same.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 27, 2018 at 2:17 PM, Julien NICOLAS 
wrote:

> Hi,
>
> I would like to optimize css and less management using gradle.
> I saw that some gradle plugins exists for transpilation (or
> compilation...) less to css and minify and gzip css files.
>
> What do you think if I try to set it in trunk ? I saw that a minifier was
> already implemented in the past but was also removed. Is there any
> technical reasons to remove minifier ?
>
> Let me know your opinions,
>
> Regards,
>
> Julien.
>

Gradle, Less, Css : Transpile and minify

[Julien NICOLAS]

Hi,

I would like to optimize css and less management using gradle.
I saw that some gradle plugins exists for transpilation (or 
compilation...) less to css and minify and gzip css files.


What do you think if I try to set it in trunk ? I saw that a minifier 
was already implemented in the past but was also removed. Is there any 
technical reasons to remove minifier ?


Let me know your opinions,

Regards,

Julien.

Policy on commit

[Jacques Le Roux]

Hi Michael, All,

First, thank you Michael for your effort in trying to clarify what to discuss in dev ML (this has already been , when to revert a commit, and I'll add 
relations with Jiras status.

I know it's important for you to correctly deliver the information about OFBiz 
activity in the monthly blog post

My goal here is to decide if we should write best practices for that in 
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices



And if yes, to clearly write them. This to avoid future confusion and conflicts 
in the community about these subjects.

Before beginning on that, I have already collected some information, I'd like to be sure we all agree about doing so. Then, if we agree we can begin 
to discuss what to write...


Thanks for your attention

Jacques


Le 19/08/2018 à 11:28, Michael Brohl a écrit :

I have not the time to dig into the specific details right now so will just 
give my thoughts on the process in general because of the citations:

1. we have to distinguish between (a) completely new functionality or major refactorings and (b) the enhancement of functionality which is already 
in the code base


2. for (a), we should first have consenus that we want the proposed solution and we should look for a complete, well designed and carefully tested 
solution before the first commit will be done. This is to prevent the introduction of new problematic code.


3. for (b), I think every improvement of existing code/functionality helps and should be committed if there are no flaws in the design or technical 
solution and it does not break existing funtionality. of course, it should be complete within the *scope* of the improvement.


4. if the solution for (b) does not cover other wishes or things which could be enhanced also, this would be no reason to not commit the 
improvement. If people have further requirements, they can provide concepts and solutions/patches anytime to make things better.


In this case, for me it is important if Suraj's commit

a. breaks anything?

b. is vetoed by other committers in view of code quality or design flaws?

If none of these questions get a "yes", then I see no reason to revert.

If you have additional requirements, you are encouraged to provide solutions or 
concepts for them.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de

Re: Editing comments in Jira

[Jacques Le Roux]

Le 27/08/2018 à 10:11, Jacques Le Roux a écrit :


Hi,

I'm in the process of trying to reduce frictions about some acts we not all 
agree about sometimes.

From my experience, establishing best practices, policy or rules does much help about that. I think the wiki is still the best place for such 
information, notably the


https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices

and

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities

pages.

While reviewing the later I stumbled upon the "Editing comments in Jira" 
information block. It says

<>

But, if I'm not wrong (I could be abused by my email clients filters) now the comments are no longer redirected to dev ML but *only* to the "new" 
notificati...@ofbiz.apache.org address.


So should we keep this sentence,? And if not, should we keep this whole 
information block?

Thanks for your attention

Jacques
BTW, thinking about it, if we keep this information block, it should not be in the committers page but contributors one. I'll check for other possible 
such cases.


Jacques

Editing comments in Jira

[Jacques Le Roux]

Hi,

I'm in the process of trying to reduce frictions about some acts we not all 
agree about sometimes.

From my experience, establishing best practices, policy or rules does much help about that. I think the wiki is still the best place for such 
information, notably the


https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices

and

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities

pages.

While reviewing the later I stumbled upon the "Editing comments in Jira" 
information block. It says

   <>

But, if I'm not wrong (I could be abused by my email clients filters) now the comments are no longer redirected to dev ML but *only* to the "new"  
notificati...@ofbiz.apache.org address.


So should we keep this sentence,? And if not, should we keep this whole 
information block?

Thanks for your attention

Jacques