Re: Hard Coded Cookie Path

[Girish Vasmatkar]

Hi Deepak

That largely depends on the use case whether to set cookie path as the root
of the web server or not. Yes, generally, it is preferred to keep the
cookies separate for the various web apps deployed on the server.

In OFBiz case, various web applications are deployed on separate mount
points and if you take, for example, the case of visitor cookie, then it
makes sense to keep it's path as root because a visitor (same person)
visiting order manager and accounting should be counted as a same and
single visitor. You do not want server to create a new visitor cookie for
order manager if the user has already visited accounting.

Browser will send the visitor cookie as part of request to order manager
that helps OFBiz identify the visitor.

Often certain other use cases demand server session to be maintained across
different web applications. Imagine a scenario where you log in to a parent
web application and then a separate module is part of a different web
application and you navigate to the sub module from the parent module. You
would ideally want the session cookie to be "transferred" from parent web
app to sub web app. Here you will have to make sure the session cookie
created by the server has the path "/" set. If that is not the case, then
navigating from parent web app to sub web app will result in session loss.

So, all in all, it is mostly based on your scenario. I hope that makes
sense.

Thanks,
Girish Vasmatkar
HotWax Systems


On Thu, Oct 4, 2018 at 4:57 PM Deepak Nigam 
wrote:

> Hello Folks,
>
> During the code walkthrough, I observed that everywhere the cookie path
> attribute is hardcoded as root '/' using the setPath() method. This is not
> the correct implementation because if the cookie path is set to the root
> '/', then the cookie will be sent to all the application under the same
> domain.
>
> Is there any best practice around this? Should it be configurable?
> IMO, the cookie path should be set to '/users/' directory. WDYT?
>
>
> Thanks!
>
> Deepak Nigam
> HotWax Systems Pvt. Ltd
>

Re: Component and Component Set Dependencies

[Jacques Le Roux]

Thanks Pierre,

I'll have a closer look. If it's only labels that can be "easily" fixed.

Jacques


Le 04/10/2018 à 14:05, Pierre Smits a écrit :

Hi Jacques, all,

Doing a search in your favourite IDE on 'manufacturing' reveals all
references. A cursory review in mine showed a lot of inclusions of the
ManufacturingUiLabels.

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 Thu, Oct 4, 2018 at 10:31 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Pierre,

Without explanation about the exact dependency from Accounting to
Manufacturing I'll remove the comments.

It would really help to have even just an idea of the kind of this/se
dependeny/ies if it's/they are still existing. Then, if they still exist, a
OFBIZ-3500 subtask could be created/

All this because I'd like to clarify the graph and remove component
dependencies when they were just due to data being in each component and
now in


https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/datamodel/data

TIA for your help

Jacques

Le 21/09/2018 à 16:20, Jacques Le Roux a écrit :

Hi Pierre,

Could you please clarify why we still need to keep these comment now that
the dependencies are in the graph.

Notably the comment you made

This diagram is missing:

- a dependency of Accounting on Manufacturing,

would be interesting if there was an explanation of the exact dependency
from Accounting on Manufacturing. If it's not data dependencies, which are
now resolved for applications.

For order on accounting code dependency, I believe it's impossible to
remove. Those need to be interconnected (eg when you send an order you need
to create an invoice).

Thanks

Jacques

Le 08/09/2018 à 11:20, Pierre Smits a écrit :

It would be better to let the comments stay until all undesirable
dependencies are removed and ticket OFBIZ-3500 has been closed.


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, Sep 8, 2018 at 11:15 AM, Deepak Dixit  

wrote:


Hi Jacques,

I think we are good and can delete the comments.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 20, 2018 at 12:22 PM, Jacques Le Roux 
 wrote:


Great, thanks Deepak

Jacques


Le 20/08/2018 à 06:20, Deepak Dixit a écrit :


Hi Jacques,

I'll check and share details ASAP.

On Sun, Aug 19, 2018 at 3:57 PM, Jacques Le Roux mailto:jacques.le.r...@les7arts.com> >
wrote:

 Hi Deepak,

 Before I remove all the comments at https://cwiki.apache.org/confl
uence/display/OFBIZ/Component+and+Component+Set+Dependencies
  

 and remove in the graph the dependency
from the
 accounting to workeffort introduced by r1710178 ;
  


 could you please confirm there is no longer data dependencies from
accounting to workeffort since we moved the data to

applications/datamodel?

 I guess there should not be and we should try to clean this graph

for

maybe other such dependencies (only because of data) now that this step

is

 almost complete (after Rishi's future effort on "Shipping data
duplicated
  
"
 thread)

 Thanks

 Jacques

Re: Component and Component Set Dependencies

[Pierre Smits]

Hi Jacques, all,

Doing a search in your favourite IDE on 'manufacturing' reveals all
references. A cursory review in mine showed a lot of inclusions of the
ManufacturingUiLabels.

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 Thu, Oct 4, 2018 at 10:31 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> Without explanation about the exact dependency from Accounting to
> Manufacturing I'll remove the comments.
>
> It would really help to have even just an idea of the kind of this/se
> dependeny/ies if it's/they are still existing. Then, if they still exist, a
> OFBIZ-3500 subtask could be created/
>
> All this because I'd like to clarify the graph and remove component
> dependencies when they were just due to data being in each component and
> now in
>
>
> https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/datamodel/data
>
> TIA for your help
>
> Jacques
>
> Le 21/09/2018 à 16:20, Jacques Le Roux a écrit :
>
> Hi Pierre,
>
> Could you please clarify why we still need to keep these comment now that
> the dependencies are in the graph.
>
> Notably the comment you made
>
> This diagram is missing:
>
>- a dependency of Accounting on Manufacturing,
>
> would be interesting if there was an explanation of the exact dependency
> from Accounting on Manufacturing. If it's not data dependencies, which are
> now resolved for applications.
>
> For order on accounting code dependency, I believe it's impossible to
> remove. Those need to be interconnected (eg when you send an order you need
> to create an invoice).
>
> Thanks
>
> Jacques
>
> Le 08/09/2018 à 11:20, Pierre Smits a écrit :
>
> It would be better to let the comments stay until all undesirable
> dependencies are removed and ticket OFBIZ-3500 has been closed.
>
>
> 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, Sep 8, 2018 at 11:15 AM, Deepak Dixit  
> 
> wrote:
>
>
> Hi Jacques,
>
> I think we are good and can delete the comments.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
> On Mon, Aug 20, 2018 at 12:22 PM, Jacques Le Roux 
>  wrote:
>
>
> Great, thanks Deepak
>
> Jacques
>
>
> Le 20/08/2018 à 06:20, Deepak Dixit a écrit :
>
>
> Hi Jacques,
>
> I'll check and share details ASAP.
>
> On Sun, Aug 19, 2018 at 3:57 PM, Jacques Le Roux 
> mailto:jacques.le.r...@les7arts.com> 
> >
> wrote:
>
> Hi Deepak,
>
> Before I remove all the comments at https://cwiki.apache.org/confl
> uence/display/OFBIZ/Component+and+Component+Set+Dependencies
>  +and+Component+Set+Dependencies> 
> 
>  and remove in the graph the dependency
> from the
> accounting to workeffort introduced by r1710178 ;
>  
> 
>
> could you please confirm there is no longer data dependencies from
> accounting to workeffort since we moved the data to
>
> applications/datamodel?
>
> I guess there should not be and we should try to clean this graph
>
> for
>
> maybe other such dependencies (only because of data) now that this step
>
> is
>
> almost complete (after Rishi's future effort on "Shipping data
> duplicated
>  904fc026f36ba5c7aa78862f72d813348b@%3Cdev.ofbiz.apache.org%3E> 
> "
>  thread)
>
> Thanks
>
> Jacques
>
>
>
>
>
>
>

Hard Coded Cookie Path

[Deepak Nigam]

Hello Folks,

During the code walkthrough, I observed that everywhere the cookie path
attribute is hardcoded as root '/' using the setPath() method. This is not
the correct implementation because if the cookie path is set to the root
'/', then the cookie will be sent to all the application under the same
domain.

Is there any best practice around this? Should it be configurable?
IMO, the cookie path should be set to '/users/' directory. WDYT?


Thanks!

Deepak Nigam
HotWax Systems Pvt. Ltd

Re: Component and Component Set Dependencies

[Jacques Le Roux]

Hi Pierre,

Without explanation about the exact dependency from Accounting to Manufacturing 
I'll remove the comments.

It would really help to have even just an idea of the kind of this/se dependeny/ies if it's/they are still existing. Then, if they still exist, a 
OFBIZ-3500 subtask could be created/


All this because I'd like to clarify the graph and remove component 
dependencies when they were just due to data being in each component and now in

   
https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/datamodel/data

TIA for your help

Jacques


Le 21/09/2018 à 16:20, Jacques Le Roux a écrit :


Hi Pierre,

Could you please clarify why we still need to keep these comment now that the 
dependencies are in the graph.

Notably the comment you made

This diagram is missing:

  * a dependency of Accounting on Manufacturing,

would be interesting if there was an explanation of the exact dependency from Accounting on Manufacturing. If it's not data dependencies, which are 
now resolved for applications.


For order on accounting code dependency, I believe it's impossible to remove. Those need to be interconnected (eg when you send an order you need to 
create an invoice).


Thanks

Jacques


Le 08/09/2018 à 11:20, Pierre Smits a écrit :

It would be better to let the comments stay until all undesirable
dependencies are removed and ticket OFBIZ-3500 has been closed.


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, Sep 8, 2018 at 11:15 AM, Deepak Dixit
wrote:


Hi Jacques,

I think we are good and can delete the comments.

Thanks & Regards
--
Deepak Dixit


On Mon, Aug 20, 2018 at 12:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Great, thanks Deepak

Jacques


Le 20/08/2018 à 06:20, Deepak Dixit a écrit :


Hi Jacques,

I'll check and share details ASAP.

On Sun, Aug 19, 2018 at 3:57 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com  >
wrote:

 Hi Deepak,

 Before I remove all the comments athttps://cwiki.apache.org/confl
uence/display/OFBIZ/Component+and+Component+Set+Dependencies
   and remove in the graph the dependency
from the
 accounting to workeffort introduced by r1710178 ;
 

 could you please confirm there is no longer data dependencies from
accounting to workeffort since we moved the data to

applications/datamodel?

 I guess there should not be and we should try to clean this graph

for

maybe other such dependencies (only because of data) now that this step

is

 almost complete (after Rishi's future effort on "Shipping data
duplicated
 " thread)

 Thanks

 Jacques