AunthenticationResource

[transmeta01]

Hi Cristian,

The job the AuthenticationResource should be done in the UserResource.
Typically, in a RESTful application, the resources are the "things"
the application handles; in our case, that would be : users,
catalogue, items, orders, brand, category...ect...These are the things
user want to manipulate (change state). There should be a 1:1
relationship between entities and resource.

Authentication should be a (one of the services) service offered by
the system. So really, the code in AuthenticationResource should be in
the UserResource and the AuthenticationResource class should not
exist.


There should also be a table for inventory and order_detail, which
should contain: the shipping address, the status of the order, a FK to
user, a company who is responsible for fulfilling the order, ect...

And also a table to contain the salt, user_id (FK)...See the
http://scrumy.com/classic website. I assigned a task to you. This
feature is important. Please implement! Ask me questions if things are
not clear or if you have a different design in mind.

Regards
Richard

[transmeta01]

One precision: the table (let's call it credential for now...) should
have an FK to user_id, the password and the salt. All data in the
table should be stored in Base64 encoded format.

Regards

On Feb 16, 10:55 pm, transmeta01 <transmet...@gmail.com> wrote:
> Hi Cristian,
>
> The job the AuthenticationResource should be done in the UserResource.
> Typically, in a RESTful application, the resources are the "things"
> the application handles; in our case, that would be : users,
> catalogue, items, orders, brand, category...ect...These are the things
> user want to manipulate (change state). There should be a 1:1
> relationship between entities and resource.
>
> Authentication should be a (one of the services) service offered by
> the system. So really, the code in AuthenticationResource should be in
> the UserResource and the AuthenticationResource class should not
> exist.
>
> There should also be a table for inventory and order_detail, which
> should contain: the shipping address, the status of the order, a FK to
> user, a company who is responsible for fulfilling the order, ect...
>

> And also a table to contain the salt, user_id (FK)...See thehttp://scrumy.com/classicwebsite. I assigned a task to you. This

[Cristian Olaru]

Hi Richard. See the comments.

On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <trans...@gmail.com> wrote:

Hi Cristian,

The job the AuthenticationResource should be done in the UserResource.
Typically, in a RESTful application, the resources are the "things"
the application handles; in our case, that would be : users,
catalogue, items, orders, brand, category...ect...These are the things
user want to manipulate (change state). There should be a 1:1
relationship between entities and resource.

Authentication should be a (one of the services) service offered by
the system. So really, the code in AuthenticationResource should be in
the UserResource and the AuthenticationResource class should not
exist.

First I introduced the authentication method in UserResource but I have the surprise to see that if I put the same REST annotation (let say PUT or POST) on two methods  the execution is random even the methods have different names - in this case I must add a different PATH I think? This is the idea? That is why I created the AuthenticationResource.

There should also be a table for inventory and order_detail, which
should contain: the shipping address, the status of the order, a FK to
user, a company who is responsible for fulfilling the order, ect...

I will implement also this.
 

And also a table to contain the salt, user_id (FK)...See the
http://scrumy.com/classic website. I assigned a task to you. This
feature is important. Please implement! Ask me questions if things are
not clear or if you have a different design in mind.

I will implement this right now.

Regards
Richard

--
Cristian Olaru
weblog: http://olaru.blogspot.com
mobile: 0743163039

[Cristian Olaru]

Hi Richard.

In fact a user has credentials to a reference from user to credential table must be defined. I will also remove the password field from user - will be in credential table. The salt will be generated when the user is registered and will be used to salt the password - also the password will be stored as a digest after registering.

I will try to use something like here: http://www.jasypt.org/howtoencryptuserpasswords.html. Maybe not the library but the recomandations.

Regards...

[Richard Mutezintare]

On Thu, Feb 17, 2011 at 1:50 AM, Cristian Olaru <col...@gmail.com> wrote:

Hi Richard. See the comments.

On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <trans...@gmail.com> wrote:

Hi Cristian,

The job the AuthenticationResource should be done in the UserResource.
Typically, in a RESTful application, the resources are the "things"
the application handles; in our case, that would be : users,
catalogue, items, orders, brand, category...ect...These are the things
user want to manipulate (change state). There should be a 1:1
relationship between entities and resource.

Authentication should be a (one of the services) service offered by
the system. So really, the code in AuthenticationResource should be in
the UserResource and the AuthenticationResource class should not
exist.

First I introduced the authentication method in UserResource but I have the surprise to see that if I put the same REST annotation (let say PUT or POST) on two methods  the execution is random even the methods have different names - in this case I must add a different PATH I think? This is the idea? That is why I created the AuthenticationResource.

I see what you mean. That is a problem with the fact the design of the resource is incomplete. Ideally, there should one verb (GET, POST, PUT, DELETE, OPTIONS, ect...) per resource. I will get back to you as I refine the resources model more and more. 

There should also be a table for inventory and order_detail, which
should contain: the shipping address, the status of the order, a FK to
user, a company who is responsible for fulfilling the order, ect...

I will implement also this.

 

Yes...and also, do you have any ideas of how to support multi-tenancy. For now, the simplest thing to do would be to just send a unique token (could be the company_id) with each request.  The company_id would be best as we could discriminate all calls to DAO with it. This would change a little our current DAO code. Let me know what you think.

[Cristian Olaru]

On Thu, Feb 17, 2011 at 7:14 PM, Richard Mutezintare <trans...@gmail.com> wrote:

On Thu, Feb 17, 2011 at 1:50 AM, Cristian Olaru <col...@gmail.com> wrote:

Hi Richard. See the comments.

On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <trans...@gmail.com> wrote:

Hi Cristian,

The job the AuthenticationResource should be done in the UserResource.
Typically, in a RESTful application, the resources are the "things"
the application handles; in our case, that would be : users,
catalogue, items, orders, brand, category...ect...These are the things
user want to manipulate (change state). There should be a 1:1
relationship between entities and resource.

Authentication should be a (one of the services) service offered by
the system. So really, the code in AuthenticationResource should be in
the UserResource and the AuthenticationResource class should not
exist.

First I introduced the authentication method in UserResource but I have the surprise to see that if I put the same REST annotation (let say PUT or POST) on two methods  the execution is random even the methods have different names - in this case I must add a different PATH I think? This is the idea? That is why I created the AuthenticationResource.

I see what you mean. That is a problem with the fact the design of the resource is incomplete. Ideally, there should one verb (GET, POST, PUT, DELETE, OPTIONS, ect...) per resource. I will get back to you as I refine the resources model more and more. 

If I introduce a different path for authentication everything is fine (In user resource):

    @PUT
    @Path("/authenticate")
    @Consumes("application/json")
    @Produces("application/json")
    public String authenticate(User user);

Somehow this new path is fine: /users/authenticate

There should also be a table for inventory and order_detail, which
should contain: the shipping address, the status of the order, a FK to
user, a company who is responsible for fulfilling the order, ect...

I will implement also this.

 

Yes...and also, do you have any ideas of how to support multi-tenancy. For now, the simplest thing to do would be to just send a unique token (could be the company_id) with each request.  The company_id would be best as we could discriminate all calls to DAO with it. This would change a little our current DAO code. Let me know what you think.

There are 2 solutions:

1 a database for each client
2 all the clients in the same database

I think you want this second case. A solution in this case is to do the token transportation from interface to database transparently using AOP, ThreadLocal, etc. But also we can propagate this on all layers: resource/service/dao/. But also in entities  I must introduce in some of them an additional field: client_id. I thisnk we must differentiate from company_id? In fact this is a question!!! We must add this client_id in other tables?

 

And also a table to contain the salt, user_id (FK)...See the
http://scrumy.com/classic website. I assigned a task to you. This
feature is important. Please implement! Ask me questions if things are
not clear or if you have a different design in mind.

I will implement this right now.

Regards
Richard

--
Cristian Olaru
weblog: http://olaru.blogspot.com
mobile: 0743163039

[Richard Mutezintare]

This makes a lot of sense. 

There should also be a table for inventory and order_detail, which
should contain: the shipping address, the status of the order, a FK to
user, a company who is responsible for fulfilling the order, ect...

I will implement also this.

 

Yes...and also, do you have any ideas of how to support multi-tenancy. For now, the simplest thing to do would be to just send a unique token (could be the company_id) with each request.  The company_id would be best as we could discriminate all calls to DAO with it. This would change a little our current DAO code. Let me know what you think.

There are 2 solutions:

1 a database for each client
2 all the clients in the same database

I think you want this second case. A solution in this case is to do the token transportation from interface to database transparently using AOP, ThreadLocal, etc. But also we can propagate this on all layers: resource/service/dao/. But also in entities  I must introduce in some of them an additional field: client_id. I thisnk we must differentiate from company_id? In fact this is a question!!! We must add this client_id in other tables?

Sounds good. By client_id, I assume you mean the company and not the actual user! Is this what you mean? Also, I think we need to think about this a little bit more. For example, one think we should consider is "scaling"...I know that may never happen, but it's good to have flexibility built into to the design. I will get back to you on that.

You have very good ideas.

[Cristian Olaru]

Hi Richard.

Please confirm me how do you want to implement the password encryption. Is strange why you want to store the salt and the password in database. Can you describe somehow the steps that you want to be done for registering/authenticate a user?

Regards...

On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <trans...@gmail.com> wrote:

[transmeta01]

Hi Cristian, the point of encrypting the password and the salt is to
add an additional layer of security. As we are dealing with customer
data, security is paramount.

So how should it work. At first, we should have a "salt generator".
This generator should generate a random salt with which we augment the
password before encryption. We need to keep the salt in DB so the that
we can decode the (password+salt) and verify user credentials.

When the user register,
1-the "salt generator", generates a salt, ([a-z]+[A-Z]+[0-9]+)
2-the salt is appended to the password [salt+password]
3-the salt+password are encrypted [SHA-256(salt+password)]
4-the salt is persisted in a table
5-the SHA-256(salt+password) is persisted as password


note: encoding of salt and password is UTF-8

Hope this helps

regards
Richard

On Feb 21, 1:55 pm, Cristian Olaru <col...@gmail.com> wrote:
> Hi Richard.
>
> Please confirm me how do you want to implement the password encryption. Is
> strange why you want to store the salt and the password in database. Can you
> describe somehow the steps that you want to be done for
> registering/authenticate a user?
>
> Regards...
>
>
>
>
>
>
>
>
>
> On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <transmet...@gmail.com> wrote:
> > Hi Cristian,
>
> > The job the AuthenticationResource should be done in the UserResource.
> > Typically, in a RESTful application, the resources are the "things"
> > the application handles; in our case, that would be : users,
> > catalogue, items, orders, brand, category...ect...These are the things
> > user want to manipulate (change state). There should be a 1:1
> > relationship between entities and resource.
>
> > Authentication should be a (one of the services) service offered by
> > the system. So really, the code in AuthenticationResource should be in
> > the UserResource and the AuthenticationResource class should not
> > exist.
>
> > There should also be a table for inventory and order_detail, which
> > should contain: the shipping address, the status of the order, a FK to
> > user, a company who is responsible for fulfilling the order, ect...
>
> > And also a table to contain the salt, user_id (FK)...See the

> >http://scrumy.com/classicwebsite. I assigned a task to you. This

[Cristian Olaru]

Hi Richard.

I didn't think that we will decode the password. In general there's a compare between the encoded texts: the password entered by user is also encoded. In the past I never compared passwords in clear.

Regards ...

[Cristian Olaru]

Hi Richard,

I pushed the changes for implementing security: see EncodingService.java for details. The tests are done in AuthenticationServiceImpl.java.

Also the salt an password are stored in DB.

I will implement in this evening the multi tenancy.

Regards...

[Cristian Olaru]

Hi Richard.

Again about multitenancy.

So, we will store multiple clients in the same database. The question is if we need to introduce this company_id in every table. We already have references to Company in this entities Catalog, Brand, Promotion. We want this companies to manage their Items, Brands, Categories, Promotions in isolation. So just for this Entities we will have a company_id discriminator?

Regards...



Hi Richard.

In the last push I created the Credential table and I will continue to implement the password encryption in this evening.

I will add

[Richard Mutezintare]

Hi Cristian, 

to help you understand, imagine this: you are a user and you login into the application. At this point you can go to any website of the product providers (our clients). So when you are viewing the products of client x, you should be served only with the promotion, catalogues, brands, ect...of client x. If you make an order, the system should be able to store the right order for the right, in this case; for client x; and not mix it with the orders for client y. 

Further, imagine this same scenario from a client (business selling a product) perspective: you want to review your order, but you should not see the order for client y and client z, nor their inventory, brands, catalogue, ect...from your store management console...At least not as a manager of a store. If you become a user, you could see all clients offering; as a regular user. 

All this to say that all resources and corresponding dao should have a discriminator based on company_id, except for the UserDAO. 

Hope this helps. Ask me more questions if you need clarifying, I will be happy to answer! 

Regards

Richard

[transmeta01]

Hi Cristian ,
decoding the password may be necessary if user forget their password.
We should be able to provide them with the same password they
registered with, hence we need to decode the password in clear text.
The option is: we could send them one of those generated, and
unintuitive, password. It would be a lot simpler. However for the sake
keeping a pleasant user experience, we should provide users with a
reminder of their original password if needed.

Regards
Richard

On Feb 22, 1:05 am, Cristian Olaru <col...@gmail.com> wrote:
> Hi Richard.
>

> I didn't think that we will decode the password. In general there's a
> compare between the encoded texts: the password entered by user is also
> encoded. In the past I never compared passwords in clear.
>
> Regards ...

[Cristian Olaru]

Hi Richard,

I have a question:

On Wed, Feb 23, 2011 at 3:19 AM, Richard Mutezintare <trans...@gmail.com> wrote:

Hi Cristian, 

to help you understand, imagine this: you are a user and you login into the application. At this point you can go to any website of the product providers (our clients). So when you are viewing the products of client x, you should be served only with the promotion, catalogues, brands, ect...of client x. If you make an order, the system should be able to store the right order for the right, in this case; for client x; and not mix it with the orders for client y. 

The question is in this case is, if  the order can contain products just from one client?  This is a logical consequence of this story. And from database point of view, I must add a company_id also in the orders table.

Further, imagine this same scenario from a client (business selling a product) perspective: you want to review your order, but you should not see the order for client y and client z, nor their inventory, brands, catalogue, ect...from your store management console...At least not as a manager of a store. If you become a user, you could see all clients offering; as a regular user. 

All this to say that all resources and corresponding dao should have a discriminator based on company_id, except for the UserDAO. 

I will add the discriminator first to  InventoryService and coresponding resurces/DAO's. Please give me a response for the previews question.
 

[Cristian Olaru]

Hi Richard.

Related to the pewviews question:
in fact I can look on the order items to see the brand owner - an in this way to decide the order owner.

Regards...

[Cristian Olaru]

Hi Richard.

I pushed something on repository. I tried to implement the ItemResource. I think that also some CRUD operations on ItemResource are not needed to be discriminated bu company_id like create/update because a Brand will be associated with it. Just the query methods if is not clear the company where the item is belong.

Maybe is better to define all the resources interfaces in src/main/java/ca/ioniq/server/resource (you can have a big contribution here as a consumer of the REST). I will continue to implement them using the services that are already done.

I will not be available for a week - the only think I can do in this period is to read email - no coding.

Regards...

[Richard Mutezintare]

On Wed, Feb 23, 2011 at 1:49 AM, Cristian Olaru <col...@gmail.com> wrote:

Hi Richard,

I have a question:

On Wed, Feb 23, 2011 at 3:19 AM, Richard Mutezintare <trans...@gmail.com> wrote:

Hi Cristian, 

to help you understand, imagine this: you are a user and you login into the application. At this point you can go to any website of the product providers (our clients). So when you are viewing the products of client x, you should be served only with the promotion, catalogues, brands, ect...of client x. If you make an order, the system should be able to store the right order for the right, in this case; for client x; and not mix it with the orders for client y. 

The question is in this case is, if  the order can contain products just from one client?  This is a logical consequence of this story. And from database point of view, I must add a company_id also in the orders table.

Yes. It is necessary for all orders to have a company_id so as to distinguish which order is to be fulfilled by which company. 

Further, imagine this same scenario from a client (business selling a product) perspective: you want to review your order, but you should not see the order for client y and client z, nor their inventory, brands, catalogue, ect...from your store management console...At least not as a manager of a store. If you become a user, you could see all clients offering; as a regular user. 

All this to say that all resources and corresponding dao should have a discriminator based on company_id, except for the UserDAO. 

I will add the discriminator first to  InventoryService and coresponding resurces/DAO's. Please give me a response for the previews question. 

Yes that would be good. The way I see, every query, on every table (except for user table) should be discriminated by company_id. If the company_id is the first discriminator in every query, once we get a fairly large data set, this should also contribute to help the performance of the queries also. Let me know is this makes sense to you.

[Richard Mutezintare]

Hi Cristian, I will have a look

On Wed, Feb 23, 2011 at 7:21 AM, Cristian Olaru <col...@gmail.com> wrote:

Hi Richard.

I pushed something on repository. I tried to implement the ItemResource. I think that also some CRUD operations on ItemResource are not needed to be discriminated bu company_id like create/update because a Brand will be associated with it. Just the query methods if is not clear the company where the item is belong.

Maybe is better to define all the resources interfaces in src/main/java/ca/ioniq/server/resource (you can have a big contribution here as a consumer of the REST). I will continue to implement them using the services that are already done.

I will not be available for a week - the only think I can do in this period is to read email - no coding.

Regards...

On Wed, Feb 23, 2011 at 4:09 AM, transmeta01 <trans...@gmail.com> wrote:

Hi Cristian ,
decoding the password may be necessary if user forget their password.
We should be able to provide them with the same password they
registered with, hence we need to decode the password in clear text.
The option is: we could send them one of those generated, and
unintuitive, password. It would be a lot simpler. However for the sake
keeping a pleasant user experience, we should provide users with a
reminder of their original password if needed.

Regards
Richard

On Feb 22, 1:05 am, Cristian Olaru <col...@gmail.com> wrote:
> Hi Richard.
>

> I didn't think that we will decode the password. In general there's a
> compare between the encoded texts: the password entered by user is also
> encoded. In the past I never compared passwords in clear.
>
> Regards ...

> On Feb 22, 2011 4:25 AM, "transmeta01" <transmet...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi Cristian, the point of encrypting the password and the salt is to
> > add an additional layer of security. As we are dealing with customer
> > data, security is paramount.
>
> > So how should it work. At first, we should have a "salt generator".
> > This generator should generate a random salt with which we augment the
> > password before encryption. We need to keep the salt in DB so the that
> > we can decode the (password+salt) and verify user credentials.
>
> > When the user register,
> > 1-the "salt generator", generates a salt, ([a-z]+[A-Z]+[0-9]+)
> > 2-the salt is appended to the password [salt+password]
> > 3-the salt+password are encrypted [SHA-256(salt+password)]
> > 4-the salt is persisted in a table
> > 5-the SHA-256(salt+password) is persisted as password
>
> > note: encoding of salt and password is UTF-8
>
> > Hope this helps
>
> > regards
> > Richard
>

> > On Feb 21, 1:55 pm, Cristian Olaru <col...@gmail.com> wrote:
> >> Hi Richard.
>

> >> Please confirm me how do you want to implement the password encryption.
> Is
> >> strange why you want to store the salt and the password in database. Can
> you
> >> describe somehow the steps that you want to be done for
> >> registering/authenticate a user?
>
> >> Regards...
>

> >> On Thu, Feb 17, 2011 at 5:55 AM, transmeta01 <transmet...@gmail.com>

> wrote:
> >> > Hi Cristian,
>
> >> > The job the AuthenticationResource should be done in the UserResource.
> >> > Typically, in a RESTful application, the resources are the "things"
> >> > the application handles; in our case, that would be : users,
> >> > catalogue, items, orders, brand, category...ect...These are the things
> >> > user want to manipulate (change state). There should be a 1:1
> >> > relationship between entities and resource.
>
> >> > Authentication should be a (one of the services) service offered by
> >> > the system. So really, the code in AuthenticationResource should be in
> >> > the UserResource and the AuthenticationResource class should not
> >> > exist.
>

> >> > There should also be a table for inventory and order_detail, which
> >> > should contain: the shipping address, the status of the order, a FK to
> >> > user, a company who is responsible for fulfilling the order, ect...
>

> >> > And also a table to contain the salt, user_id (FK)...See the

> >> >http://scrumy.com/classicwebsite. I assigned a task to you. This

> >> > feature is important. Please implement! Ask me questions if things are
> >> > not clear or if you have a different design in mind.
>

> >> > Regards
> >> > Richard
>
> >> --
> >> Cristian Olaru
> >> weblog:http://olaru.blogspot.com
> >> mobile: 0743163039

[Cristian Olaru]

Hi Richard!  I added code for other resources including Order resource. I will continue tommorow with other resources. Regards...

[Richard Mutezintare]

Hi Cristian, I will have a look and get back to you.

Richard

sent from android 2.3