Re: public rest API

[Hans Bakker]

Hi Girish,

i did a quit check using flutter test this morning and it looks like it 
is working fine.


for people interested in using flutter(http://flutter.dev) with ofbiz:
    the test: 
https://github.com/growerp/growerp/blob/master/test/services/ofbiz_testManual.dart
    if you want to run you need to install the growerp plugin into 
ofbiz: https://github.com/growerp/growerp-ofbiz


Thank you Girish for this enhancement and keep up the good work!

Regards,

Hans Bakker
http://www.antwebsystems.com

On 9/26/20 4:05 PM, Girish Vasmatkar wrote:

Hello Hans

With the latest commi1361c3c 
 on 
trunk, the system now honours the "auth" attribute defined on service 
and accordingly bypasses authorization for such services.


Best,
Girish


On Thu, Sep 10, 2020 at 5:46 PM Hans Bakker 
mailto:h.bak...@antwebsystems.com>> wrote:


Thank you Girish,

look forward to your updates of this excellent and much needed
addition to OFBiz.

Regars

Hans
www.antwebsystems.com 

On 9/10/20 3:27 PM, Girish Vasmatkar wrote:

Thanks Hans, I will plan to include this change for the
exportable services as well.

There is also OFBIZ-11995, where more RESTFul resources can be
declared (development is undergoing) and bound to services where
I had planned to include declarative authentication.
*
*
Best Regards,
Girish Vasmatkar
HotWax Systems




On Thu, Sep 10, 2020 at 12:08 PM Hans Bakker
mailto:h.bak...@antwebsystems.com>>
wrote:

Hi Girish,

how about ecommerce? you want to show the products without
logging in,
actually all information on the ecommerce frontend?

so yes, really required.

regards,

Hans


On 9/10/20 12:37 PM, Girish Vasmatkar wrote:
> Every REST endpoint, as it is implemented now, is secured
by default. I had
> not thought of a scenario where internal OFBiz services
will need to be
> invoked without authentication (externally)
>
> Yes, the services themselves can be specified to NOT
require auth but I had
> always thought that was applicable within internal
execution. I may be
> wrong here, so please correct me.
>
> auth and login-required are not taken into account yet, but
can certainly
> be, if some exportable services should be exposed as public
APIs.
>
> Best Regards,
> Girish Vasmatkar
> HotWax Systems
>
>
>
> On Thu, Sep 10, 2020 at 5:55 AM Hans Bakker
mailto:h.bak...@antwebsystems.com>>
> wrote:
>
>> Hi, Girish,
>>
>> thanks again for your last reply it defenity helped,
however i have
>> another question.
>>
>> I need to access certain services publicly without a token.
>>
>> I have put auth="false" on the service definition and
>> login-required="false" on the simple-method implementation
>>
>> still i get a 401 response.
>>
>> any suggestions?
>>
>> Regards,
>>
>> Hans
>>
>>

Re: OFBiz as OMS

[Devanshu Vyas]

Hello, We just finished our first discussion on OFBiz as Open Source OMS.
Thank you to all the participants joining in. The video is now published on
the OFBiz Youtube Channel. Here is the link: https://youtu.be/37E777O7050
This will be a series of videos where we will be discussing this topic.
Here is the link for the playlist:
https://www.youtube.com/playlist?list=PLobIkeUbRXqe7YKSOdrXTrbRlCa7xvyGe

We have finalized a schedule to continue our discussions on this topic,
which is every Tuesday at 4 PM IST.
29th September 2020 Real-time inventory visibility
6th October 2020 Order routing to a facility for fulfilment
13th October 2020 Order splitting of available items for faster fulfilment
20th October 2020 Fulfilment application to be used at Stores(BOSS - Buy
Online Ship-to-Store)
27th October 2020 Store inventory management
3rd November 2020 Integrations with applications like BOPIS(Buy Online and
Pick in Store), BORIS(Buy Online Return in Store), and Endless Aisle.
10th November 2020 Preorder and Backorder Management

@Deepak, It was an impromptu session, and at the last minute, we thought of
including anyone who wants to join.
I have prepared and shared the schedule of each discussion we will be doing
on this topic.

@Joseph, I hope to see you in the next discussion.


Thanks & Regards,
Devanshu Vyas.


On Sat, Sep 26, 2020 at 5:40 PM Deepak Dixit  wrote:

> Hi Devanshu,
>
> It'd be good if you share this kind of information little early, In the
> planned way you will get more participation.
>
>
> Kind Regards,
> Deepak Dixit
>
>
>
> On Sat, Sep 26, 2020 at 4:12 PM Devanshu Vyas 
> wrote:
>
> > Hello,
> >
> > We are going to start the discussion on 'OFBiz as OMS' today at 4:30 PM
> > IST. If you are interested in joining, please share your interest here
> and
> > I'll send you a link.
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
>

Re: Welcome Swapnil Shah as new PMC member!!

[Pranay Pandey]

Congratulations Swapnil!
Best regards,
Pranay Pandey


On Sat, Sep 26, 2020 at 7:10 PM Swapnil Shah 
wrote:

> Thank you everyone for your continuous support and kind wishes.
>
> Thanks,
> Swapnil
>
> > -Original Message-
> > From: Ashish Vijaywargiya 
> > Sent: 18 September 2020 12:56
> > To: dev@ofbiz.apache.org
> > Subject: Welcome Swapnil Shah as new PMC member!!
> >
> > The OFBiz PMC has invited Swapnil Shah to become a member of the
> committee
> > and we are glad to announce that he has accepted the nomination.
> >
> > On behalf of the OFBiz PMC, welcome on board Swapnil!
>

Re: [PROPOSAL] Separate login service for API calls

[Jacques Le Roux]

+1

Jacques

Le 26/09/2020 à 13:56, Deepak Dixit a écrit :

Hi Girish,

I think it's a good idea to use a separate login method for REST to
avoid sessions.

We have *userLogin* service that do the login related work, so we can have
separate wrapper method for REST like LoginWorker.login()


Kind Regards,
Deepak Dixit


On Sat, Sep 26, 2020 at 2:54 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hello
I am not sure if we can talk about sessions when we're talking about REST.
The REST implementation is mapping Resources with OFBiz services and the
services are executing in a context using "userLogin" and that is all the
REST implementation is doing. Extracting userLogin from token and supplying
to the OFBiz service.

The session you get from running userLogin service is not getting used for
subsequent API calls made using JWT token because usual OFBiz flow
(ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
as far as REST implementation is concerned, it is better to create a
separate service that does just authentication and doesn't create sessions.

Also, a properly designed REST endpoint without cookies means no CSRF.

Best,
Girish
HotWax System








On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Gavin,

I'd just note that in this case your are not protected from CSRF.
Fortunately the REST effort is only in trunk. And, as explained in
security.properties, in trunk we can use
org.apache.ofbiz.security.CsrfDefenseStrategy in such case.

Jacques

Le 26/09/2020 à 07:38, Gavin Mabie a écrit :

Sessions are extremely useful and even indispensable for an ERP system
where statefullnes are critical for audit trail purposes. Stateless
requests don't care about transactions beyond the actual

request/response.

Besides, sessions are only problematic when a new session gets created

for

each REST API request. You can prevent this by setting the cookie

SameSite

property to "None".  That way sessions and REST request can happily

live

together.

On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hi

I am using userLogin service to authenticate users before generating

auth

tokens for REST API and GraphQL calls. However, I figured that a

session is

also getting created and returned in response which is defeating the
purpose of having an API in place. Even though that session is not

getting

used anywhere when subsequent calls are made using the token, I still

think

it is an extra session lying around in tomcat's session cache.

I propose to implement a new basic userLogin service

(basicAuthUserLogin)

that would just do username/password matching and be done with it

without

ever calling request.getSession(). This will ensure that APIs are

stateless

and no session is generated.

Anything else you think should be part of the new service instead of

just

username/password validation?

Best,
Girish
HotWax Systems

RE: Welcome Swapnil Shah as new PMC member!!

[Swapnil Shah]

Thank you everyone for your continuous support and kind wishes.

Thanks,
Swapnil

> -Original Message-
> From: Ashish Vijaywargiya 
> Sent: 18 September 2020 12:56
> To: dev@ofbiz.apache.org
> Subject: Welcome Swapnil Shah as new PMC member!!
>
> The OFBiz PMC has invited Swapnil Shah to become a member of the committee
> and we are glad to announce that he has accepted the nomination.
>
> On behalf of the OFBiz PMC, welcome on board Swapnil!

Re: [PROPOSAL] Separate login service for API calls

[Gavin Mabie]

You're right Jacques.  SameState=None exposes CSRF. Thanks for pointing
that out.

On Sat, Sep 26, 2020 at 10:34 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Gavin,
>
> I'd just note that in this case your are not protected from CSRF.
> Fortunately the REST effort is only in trunk. And, as explained in
> security.properties, in trunk we can use
> org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
>
> Jacques
>
> Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > Sessions are extremely useful and even indispensable for an ERP system
> > where statefullnes are critical for audit trail purposes. Stateless
> > requests don't care about transactions beyond the actual
> request/response.
> > Besides, sessions are only problematic when a new session gets created
> for
> > each REST API request. You can prevent this by setting the cookie
> SameSite
> > property to "None".  That way sessions and REST request can happily live
> > together.
> >
> > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> >> Hi
> >>
> >> I am using userLogin service to authenticate users before generating
> auth
> >> tokens for REST API and GraphQL calls. However, I figured that a
> session is
> >> also getting created and returned in response which is defeating the
> >> purpose of having an API in place. Even though that session is not
> getting
> >> used anywhere when subsequent calls are made using the token, I still
> think
> >> it is an extra session lying around in tomcat's session cache.
> >>
> >> I propose to implement a new basic userLogin service
> (basicAuthUserLogin)
> >> that would just do username/password matching and be done with it
> without
> >> ever calling request.getSession(). This will ensure that APIs are
> stateless
> >> and no session is generated.
> >>
> >> Anything else you think should be part of the new service instead of
> just
> >> username/password validation?
> >>
> >> Best,
> >> Girish
> >> HotWax Systems
> >>
>

Re: Welcome Mridul Pathak as new PMC member!!

[Deepak Dixit]

Many many congrats Mridul 

Thanks & Regards
—
Deepak Dixit

On Sat, 26 Sep 2020 at 6:09 PM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

> Many congratulations Mridul!
>
>
>
> Best regards,
>
> Pranay Pandey
>
>
>
>
>
> On Fri, Sep 18, 2020 at 12:55 PM Ashish Vijaywargiya 
>
> wrote:
>
>
>
> > The OFBiz PMC has invited Mridul Pathak to become a member of the
> committee
>
> > and we are glad to announce that he has accepted the nomination.
>
> >
>
> > On behalf of the OFBiz PMC, welcome on board Mridul!
>
> >
>
> --
Thanks & Regards
—
Deepak Dixit

Re: Welcome Mridul Pathak as new PMC member!!

[Pranay Pandey]

Many congratulations Mridul!

Best regards,
Pranay Pandey


On Fri, Sep 18, 2020 at 12:55 PM Ashish Vijaywargiya 
wrote:

> The OFBiz PMC has invited Mridul Pathak to become a member of the committee
> and we are glad to announce that he has accepted the nomination.
>
> On behalf of the OFBiz PMC, welcome on board Mridul!
>

RE: Welcome Mridul Pathak as new PMC member!!

[Swapnil Shah]

Many congratulations Mridul !!

Thanks,
Swapnil

> -Original Message-
> From: Ashish Vijaywargiya 
> Sent: 18 September 2020 12:55
> To: dev@ofbiz.apache.org
> Subject: Welcome Mridul Pathak as new PMC member!!
>
> The OFBiz PMC has invited Mridul Pathak to become a member of the
> committee and we are glad to announce that he has accepted the nomination.
>
> On behalf of the OFBiz PMC, welcome on board Mridul!

Re: OFBiz as Open Source Order Management System

[Arpit Mor]

Hello Pranay,

Thanks for bringing this up. I totally agree with the point that you have
mentioned in the mail and Wiki. The arena indeed has changed and
specialization is the key. In most cases, established brands already have
legacy software and if we want them to consider OFBiz as their OMS then it
should be easy and cost-effective to integrate with their legacy software.
As you have mentioned, Headless Commerce Plugin can play a very
significant role in achieving this.

We are already preparing a plan for a Headless Commerce Plugin for
eCommerce, we should also consider a Headless Commerce Plugin for OMS as
well.

Please count me in for planning and discussion.

Thanks

Arpit Mor
ENTERPRISE QUALITY ENGINEER
mobile: +91 9098005893
email: arpit@hotwaxsystems.com
*www.hotwax.co *


On Tue, Sep 22, 2020 at 2:02 PM Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

> Thanks Devanshu, we can surely do it.
>
> Kind regards,
> Pranay Pandey
>
> On Tue, 22 Sep 2020 at 9:54 AM, Devanshu Vyas 
> wrote:
>
> > Hello Pranay,
> >
> > The document you created has all the necessary information for us to
> start
> > thinking about OFBIZ as an OMS. And yes, with the 'headless commerce
> plugin
> > for OFBiz' is already in discussion, gives us a motivation to start
> > brainstorming on this.
> >
> > I would like to extend my help in any way required and I would recommend
> > let's do an initial meet/skype to plan how we can take this forward.
> >
> >
> > Thanks & Regards,
> > Devanshu Vyas.
> >
> >
> > On Tue, Aug 25, 2020 at 6:16 PM Pranay Pandey <
> > pranay.pan...@hotwaxsystems.com> wrote:
> >
> >> Hello Devs,
> >>
> >>
> >>
> >>
> >>
> >> In connection to the proposal that Arpit Mor has initiated on the thread
> >>
> >>
> >> "Headless Commerce Plugin for OFBiz", I wanted to request your thoughts
> on
> >>
> >>
> >> the topic "OFBiz as Order Management System". Here is a draft for your
> >>
> >>
> >> review and feedback [1].
> >>
> >>
> >>
> >>
> >>
> >> The thought is to consider OFBiz as an Open Source alternative for
> >>
> >>
> >> Omnichannel Order Management System. Based on experience from the last
> >>
> >>
> >> decade, it's found that now the arena has changed and specialization is
> >> the
> >>
> >>
> >> key. Looking at the current scenario, businesses are looking for
> >>
> >>
> >> cloud-native, cost-effective specialized solutions, and positioning
> OFBiz
> >>
> >>
> >> in that space can help a wide user community. It will help us spread the
> >>
> >>
> >> word as well.
> >>
> >>
> >>
> >>
> >>
> >> Please take a look at the document and put your thoughts on it.
> >>
> >>
> >>
> >>
> >>
> >> [1] OFBiz as Open Source Order Management System
> >>
> >>
> >> 
> >>
> >>
> >>
> >>
> >>
> >> Kind regards,
> >>
> >>
> >> Pranay Pandey
> >>
> >>
> >>
> >
> > --
> Best regards,
>
> Pranay Pandey
> mobile: +91 9826035576
> email: pranay.pan...@hotwax.co
> www.hotwax.co
>

Re: [PROPOSAL] Separate login service for API calls

[Deepak Dixit]

Hi Girish,

I think it's a good idea to use a separate login method for REST to
avoid sessions.

We have *userLogin* service that do the login related work, so we can have
separate wrapper method for REST like LoginWorker.login()


Kind Regards,
Deepak Dixit


On Sat, Sep 26, 2020 at 2:54 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hello
> I am not sure if we can talk about sessions when we're talking about REST.
> The REST implementation is mapping Resources with OFBiz services and the
> services are executing in a context using "userLogin" and that is all the
> REST implementation is doing. Extracting userLogin from token and supplying
> to the OFBiz service.
>
> The session you get from running userLogin service is not getting used for
> subsequent API calls made using JWT token because usual OFBiz flow
> (ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
> as far as REST implementation is concerned, it is better to create a
> separate service that does just authentication and doesn't create sessions.
>
> Also, a properly designed REST endpoint without cookies means no CSRF.
>
> Best,
> Girish
> HotWax System
>
>
>
>
>
>
>
>
> On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Thanks Gavin,
> >
> > I'd just note that in this case your are not protected from CSRF.
> > Fortunately the REST effort is only in trunk. And, as explained in
> > security.properties, in trunk we can use
> > org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
> >
> > Jacques
> >
> > Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > > Sessions are extremely useful and even indispensable for an ERP system
> > > where statefullnes are critical for audit trail purposes. Stateless
> > > requests don't care about transactions beyond the actual
> > request/response.
> > > Besides, sessions are only problematic when a new session gets created
> > for
> > > each REST API request. You can prevent this by setting the cookie
> > SameSite
> > > property to "None".  That way sessions and REST request can happily
> live
> > > together.
> > >
> > > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > > girish.vasmat...@hotwaxsystems.com> wrote:
> > >
> > >> Hi
> > >>
> > >> I am using userLogin service to authenticate users before generating
> > auth
> > >> tokens for REST API and GraphQL calls. However, I figured that a
> > session is
> > >> also getting created and returned in response which is defeating the
> > >> purpose of having an API in place. Even though that session is not
> > getting
> > >> used anywhere when subsequent calls are made using the token, I still
> > think
> > >> it is an extra session lying around in tomcat's session cache.
> > >>
> > >> I propose to implement a new basic userLogin service
> > (basicAuthUserLogin)
> > >> that would just do username/password matching and be done with it
> > without
> > >> ever calling request.getSession(). This will ensure that APIs are
> > stateless
> > >> and no session is generated.
> > >>
> > >> Anything else you think should be part of the new service instead of
> > just
> > >> username/password validation?
> > >>
> > >> Best,
> > >> Girish
> > >> HotWax Systems
> > >>
> >
>

Re: public rest API

[Chandan Khandelwal]

Hi Girish,

I have gone through the implementation and tested it on API client with
HTTP bearer token authentication and worked for me for both auth=
true/false (bypass authorization).

Kind Regards,
Chandan Khandelwal



On Sat, Sep 26, 2020 at 2:35 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hello Hans
>
> With the latest commi1361c3c
> <
> https://github.com/apache/ofbiz-plugins/commit/1361c3cdaf7d6756cc9abdc6c37450ef3d46f921
> >
> on
> trunk, the system now honours the "auth" attribute defined on service and
> accordingly bypasses authorization for such services.
>
> Best,
> Girish
>
>
> On Thu, Sep 10, 2020 at 5:46 PM Hans Bakker 
> wrote:
>
> > Thank you Girish,
> >
> > look forward to your updates of this excellent and much needed addition
> to
> > OFBiz.
> >
> > Regars
> >
> > Hans
> > www.antwebsystems.com
> > On 9/10/20 3:27 PM, Girish Vasmatkar wrote:
> >
> > Thanks Hans, I will plan to include this change for the exportable
> > services as well.
> >
> > There is also OFBIZ-11995, where more RESTFul resources can be declared
> > (development is undergoing) and bound to services where I had planned to
> > include declarative authentication.
> >
> > Best Regards,
> > Girish Vasmatkar
> > HotWax Systems
> >
> >
> >
> >
> > On Thu, Sep 10, 2020 at 12:08 PM Hans Bakker  >
> > wrote:
> >
> >> Hi Girish,
> >>
> >> how about ecommerce? you want to show the products without logging in,
> >> actually all information on the ecommerce frontend?
> >>
> >> so yes, really required.
> >>
> >> regards,
> >>
> >> Hans
> >>
> >>
> >> On 9/10/20 12:37 PM, Girish Vasmatkar wrote:
> >> > Every REST endpoint, as it is implemented now, is secured by default.
> I
> >> had
> >> > not thought of a scenario where internal OFBiz services will need to
> be
> >> > invoked without authentication (externally)
> >> >
> >> > Yes, the services themselves can be specified to NOT require auth but
> I
> >> had
> >> > always thought that was applicable within internal execution. I may be
> >> > wrong here, so please correct me.
> >> >
> >> > auth and login-required are not taken into account yet, but can
> >> certainly
> >> > be, if some exportable services should be exposed as public APIs.
> >> >
> >> > Best Regards,
> >> > Girish Vasmatkar
> >> > HotWax Systems
> >> >
> >> >
> >> >
> >> > On Thu, Sep 10, 2020 at 5:55 AM Hans Bakker <
> h.bak...@antwebsystems.com
> >> >
> >> > wrote:
> >> >
> >> >> Hi, Girish,
> >> >>
> >> >> thanks again for your last reply it defenity helped, however i have
> >> >> another question.
> >> >>
> >> >> I need to access certain services publicly without a token.
> >> >>
> >> >> I have put auth="false" on the service definition and
> >> >> login-required="false" on the simple-method implementation
> >> >>
> >> >> still i get a 401 response.
> >> >>
> >> >> any suggestions?
> >> >>
> >> >> Regards,
> >> >>
> >> >> Hans
> >> >>
> >> >>
> >>
> >
>

UPDATE: OFBiz code linting issues

[Suraj Khurana]

Hello team,

Sometimes back, we introduced sonar and checkstyle linting tools integrated
with OFBiz.
We as a community are serious not only about features being introduced in
OFBiz but also code quality being added in the repo.
So we started correcting issues identified by the linting tool (checkstyle)
and there were nearly ~*40,000* of those in the whole codebase.

Slowly we keep on discussing it on different mail threads and move towards
conclusions and fix those into the code base.
We also incorporated a pre-push commit hook to ensure that no new issues
are being introduced by committers.

I am glad to announce that we have fixed around *99%* of these issues
successfully.
Kudos to everyone involved in this effort !!

--
Best Regards,
Suraj Khurana
Senior Technical Consultant

Re: [PROPOSAL] Separate login service for API calls

[Girish Vasmatkar]

Hello
I am not sure if we can talk about sessions when we're talking about REST.
The REST implementation is mapping Resources with OFBiz services and the
services are executing in a context using "userLogin" and that is all the
REST implementation is doing. Extracting userLogin from token and supplying
to the OFBiz service.

The session you get from running userLogin service is not getting used for
subsequent API calls made using JWT token because usual OFBiz flow
(ContextFilter, ControlServlet) don't come in picture. Therefore, I feel,
as far as REST implementation is concerned, it is better to create a
separate service that does just authentication and doesn't create sessions.

Also, a properly designed REST endpoint without cookies means no CSRF.

Best,
Girish
HotWax System








On Sat, Sep 26, 2020 at 2:04 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Gavin,
>
> I'd just note that in this case your are not protected from CSRF.
> Fortunately the REST effort is only in trunk. And, as explained in
> security.properties, in trunk we can use
> org.apache.ofbiz.security.CsrfDefenseStrategy in such case.
>
> Jacques
>
> Le 26/09/2020 à 07:38, Gavin Mabie a écrit :
> > Sessions are extremely useful and even indispensable for an ERP system
> > where statefullnes are critical for audit trail purposes. Stateless
> > requests don't care about transactions beyond the actual
> request/response.
> > Besides, sessions are only problematic when a new session gets created
> for
> > each REST API request. You can prevent this by setting the cookie
> SameSite
> > property to "None".  That way sessions and REST request can happily live
> > together.
> >
> > On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> >> Hi
> >>
> >> I am using userLogin service to authenticate users before generating
> auth
> >> tokens for REST API and GraphQL calls. However, I figured that a
> session is
> >> also getting created and returned in response which is defeating the
> >> purpose of having an API in place. Even though that session is not
> getting
> >> used anywhere when subsequent calls are made using the token, I still
> think
> >> it is an extra session lying around in tomcat's session cache.
> >>
> >> I propose to implement a new basic userLogin service
> (basicAuthUserLogin)
> >> that would just do username/password matching and be done with it
> without
> >> ever calling request.getSession(). This will ensure that APIs are
> stateless
> >> and no session is generated.
> >>
> >> Anything else you think should be part of the new service instead of
> just
> >> username/password validation?
> >>
> >> Best,
> >> Girish
> >> HotWax Systems
> >>
>

Re: public rest API

[Girish Vasmatkar]

Hello Hans

With the latest commi1361c3c

on
trunk, the system now honours the "auth" attribute defined on service and
accordingly bypasses authorization for such services.

Best,
Girish


On Thu, Sep 10, 2020 at 5:46 PM Hans Bakker 
wrote:

> Thank you Girish,
>
> look forward to your updates of this excellent and much needed addition to
> OFBiz.
>
> Regars
>
> Hans
> www.antwebsystems.com
> On 9/10/20 3:27 PM, Girish Vasmatkar wrote:
>
> Thanks Hans, I will plan to include this change for the exportable
> services as well.
>
> There is also OFBIZ-11995, where more RESTFul resources can be declared
> (development is undergoing) and bound to services where I had planned to
> include declarative authentication.
>
> Best Regards,
> Girish Vasmatkar
> HotWax Systems
>
>
>
>
> On Thu, Sep 10, 2020 at 12:08 PM Hans Bakker 
> wrote:
>
>> Hi Girish,
>>
>> how about ecommerce? you want to show the products without logging in,
>> actually all information on the ecommerce frontend?
>>
>> so yes, really required.
>>
>> regards,
>>
>> Hans
>>
>>
>> On 9/10/20 12:37 PM, Girish Vasmatkar wrote:
>> > Every REST endpoint, as it is implemented now, is secured by default. I
>> had
>> > not thought of a scenario where internal OFBiz services will need to be
>> > invoked without authentication (externally)
>> >
>> > Yes, the services themselves can be specified to NOT require auth but I
>> had
>> > always thought that was applicable within internal execution. I may be
>> > wrong here, so please correct me.
>> >
>> > auth and login-required are not taken into account yet, but can
>> certainly
>> > be, if some exportable services should be exposed as public APIs.
>> >
>> > Best Regards,
>> > Girish Vasmatkar
>> > HotWax Systems
>> >
>> >
>> >
>> > On Thu, Sep 10, 2020 at 5:55 AM Hans Bakker > >
>> > wrote:
>> >
>> >> Hi, Girish,
>> >>
>> >> thanks again for your last reply it defenity helped, however i have
>> >> another question.
>> >>
>> >> I need to access certain services publicly without a token.
>> >>
>> >> I have put auth="false" on the service definition and
>> >> login-required="false" on the simple-method implementation
>> >>
>> >> still i get a 401 response.
>> >>
>> >> any suggestions?
>> >>
>> >> Regards,
>> >>
>> >> Hans
>> >>
>> >>
>>
>

Encoding issues with product names

[Amit Gadaley]

Hello All,

Recently working for a client I encountered a weird issue related to
special characters encodings. We have product names containing special
characters like ' (apostrophes). When we create orders for it, an encoded
value for it is stored in OrderItem.itemDescription. The same encoded value
also copied for invoice and return. When I checked the Product entity
record, the original value (name without encoding) was stored there. I
debugged the issue at code level and found that the system does encoding
(string or html) at the time of order creation.

I understand that for security reasons (and I want to know more about it),
the system does the encodings. My concerns are related to not using
encoding when we create products. And it is not good UI experience to
display encoded forms of values to screens.

I suggest we should use some methods to display encoded values properly on
screens or remove the encoding at the very first place.

Please feel free to provide any suggestions or inputs.

-- 
Kind Regards,
Amit Gadaley
*Technical Consultant*
*HotWax Systems*
*Enterprise open source experts*
cell: +91-95845-93069
office: 0731-409-3684
http://www.hotwaxsystems.com

Re: [PROPOSAL] Separate login service for API calls

[Jacques Le Roux]

Thanks Gavin,

I'd just note that in this case your are not protected from CSRF. Fortunately the REST effort is only in trunk. And, as explained in 
security.properties, in trunk we can use org.apache.ofbiz.security.CsrfDefenseStrategy in such case.


Jacques

Le 26/09/2020 à 07:38, Gavin Mabie a écrit :

Sessions are extremely useful and even indispensable for an ERP system
where statefullnes are critical for audit trail purposes. Stateless
requests don't care about transactions beyond the actual request/response.
Besides, sessions are only problematic when a new session gets created for
each REST API request. You can prevent this by setting the cookie SameSite
property to "None".  That way sessions and REST request can happily live
together.

On Sat, Sep 26, 2020 at 6:35 AM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:


Hi

I am using userLogin service to authenticate users before generating auth
tokens for REST API and GraphQL calls. However, I figured that a session is
also getting created and returned in response which is defeating the
purpose of having an API in place. Even though that session is not getting
used anywhere when subsequent calls are made using the token, I still think
it is an extra session lying around in tomcat's session cache.

I propose to implement a new basic userLogin service (basicAuthUserLogin)
that would just do username/password matching and be done with it without
ever calling request.getSession(). This will ensure that APIs are stateless
and no session is generated.

Anything else you think should be part of the new service instead of just
username/password validation?

Best,
Girish
HotWax Systems

Re: varchar(255) in fieldtypepostgres.xml

[Jacques Le Roux]

Hi All,

d...@dlsemc.com has suggested a good solution at OFBIZ-12021. I'll apply it in 
a week if nobody is against.

Thanks

Jacques

Le 10/08/2020 à 20:30, Development a écrit :

In /framework/entity/fieldtype/fieldtypepostgres.xml I saw some lines like:

 
 
 


In postgres, using "VARCHAR(255)" saves no space in the database over using "VARCHAR" 
(with no number) or "TEXT", the only difference is that the 255 slows it down with error checking.

Is there any reason on the ofbiz side to not just change this to plain "VARCHAR" or 
"TEXT"?  Like perhaps the forms would only display the first 255 characters of it or 
something?

Obviously I can do this for my own installation.  I'm asking here cause it 
feels like something that should be pushed upstream.







CONFIDENTIALITY NOTICE: This message is intended only for the use of the person 
or organization to which it is addressed or was intended to be addressed, and 
may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the 
intended recipient, or responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify the sender immediately by email and 
delete the original message immediately . The sender, its subsidiaries and 
affiliates, do not accept liability for any errors, omissions, corruption or 
virus in the contents of this message or any attachments that arise as a result 
of e-mail transmission. Thank you.