Manage API Keys

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Hi Lukasz,

I certainly envisioned #1 and not #2. Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens. I don’t think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we’re interested in are closer to what we’ve called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant. It’s more than okay here to start small: we know that a first pass for these API tokens don’t have options an administrator selects when creating them, it’ll just be for certain CCE endpoints. In the near future we’ll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,
Josh

···

On Tuesday, December 12, 2017 at 3:38:03 AM UTC-8, Łukasz Lewczyński wrote:

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Hi Josh,

Thanks for response, I will start working on solution #1. I think for now there is also one more problem with this solution. We will treat the API keys as a service-based tokens and currently all those tokens (if endpoint support it) have access to everything. I know in the future those tokens will have some roles/rights assigned so the problem will be resolved in the future.

Regards,

Lukasz


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Dec 13, 2017 at 6:04 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Hi Lukasz,

I certainly envisioned #1 and not #2. Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens. I don’t think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we’re interested in are closer to what we’ve called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant. It’s more than okay here to start small: we know that a first pass for these API tokens don’t have options an administrator selects when creating them, it’ll just be for certain CCE endpoints. In the near future we’ll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,
Josh

On Tuesday, December 12, 2017 at 3:38:03 AM UTC-8, Łukasz Lewczyński wrote:

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

**
SolDevelo** Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/b676d308-e4ae-4f17-ac65-f5a9c4fcd370%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Hi Lukasz,

I’m not sure I follow. I’m not suggesting that this api token give access to everything. Just the places that accept it. This may require some work to clarify service tokens. I think you’ll need to advise us with how best the current structure should be amended in the service code. I wanted you to be reassured that we do in fact want to use OAuth2 bearer tokens.

Best,

Josh

···

On Wed, Dec 13, 2017 at 6:04 AM, Josh Zamor
josh.zamor@villagereach.org wrote:

Hi Lukasz,

I certainly envisioned #1 and not #2. Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens. I don’t think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we’re interested in are closer to what we’ve called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant. It’s more than okay here to start small: we know that a first pass for these API tokens don’t have options an administrator selects when creating them, it’ll just be for certain CCE endpoints. In the near future we’ll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,

Josh

On Tuesday, December 12, 2017 at 3:38:03 AM UTC-8, Łukasz Lewczyński wrote:

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/b676d308-e4ae-4f17-ac65-f5a9c4fcd370%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

Hi Josh,

I described the problem on the slack channel and in the end to find out if the authentication should be treated as service level request it should have client id equals to the value which is in the auth.server.clientId property from the application.properties. As part of the work I will block access to the all endpoints that check if user has right to call an endpoint with parameters. Is that sound okay for you?

Regards,

Lukasz


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Dec 13, 2017 at 9:59 PM, Josh Zamor josh.zamor@villagereach.org wrote:

Hi Lukasz,

I’m not sure I follow. I’m not suggesting that this api token give access to everything. Just the places that accept it. This may require some work to clarify service tokens. I think you’ll need to advise us with how best the current structure should be amended in the service code. I wanted you to be reassured that we do in fact want to use OAuth2 bearer tokens.

Best,

Josh

On Dec 12, 2017, at 11:43 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi Josh,

Thanks for response, I will start working on solution #1. I think for now there is also one more problem with this solution. We will treat the API keys as a service-based tokens and currently all those tokens (if endpoint support it) have access to everything. I know in the future those tokens will have some roles/rights assigned so the problem will be resolved in the future.

Regards,

Lukasz

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/1A011DE8-2B66-47CD-BFAC-8C70FDEC2E1F%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

On Wed, Dec 13, 2017 at 6:04 AM, Josh Zamor
josh.zamor@villagereach.org wrote:

Hi Lukasz,

I certainly envisioned #1 and not #2. Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens. I don’t think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we’re interested in are closer to what we’ve called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant. It’s more than okay here to start small: we know that a first pass for these API tokens don’t have options an administrator selects when creating them, it’ll just be for certain CCE endpoints. In the near future we’ll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,

Josh

On Tuesday, December 12, 2017 at 3:38:03 AM UTC-8, Łukasz Lewczyński wrote:

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/b676d308-e4ae-4f17-ac65-f5a9c4fcd370%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

Hi all,

Regarding checking if client id equals to the value which is in the auth.server.clientId property, is it safe to assume that there will be only one “trusted client” for service-based token?

Best regards,

Paweł


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Thu, Dec 14, 2017 at 8:12 AM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi Josh,

I described the problem on the slack channel and in the end to find out if the authentication should be treated as service level request it should have client id equals to the value which is in the auth.server.clientId property from the application.properties. As part of the work I will block access to the all endpoints that check if user has right to call an endpoint with parameters. Is that sound okay for you?

Regards,

Lukasz


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53xyDVasDNKTyJE%2BgQJwo8M6oAcuKhSuDN7fUaD8K6Hchw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Łukasz Lewczyński
Software Developer
llewczynski@soldevelo.com

On Wed, Dec 13, 2017 at 9:59 PM, Josh Zamor josh.zamor@villagereach.org wrote:

Hi Lukasz,

I’m not sure I follow. I’m not suggesting that this api token give access to everything. Just the places that accept it. This may require some work to clarify service tokens. I think you’ll need to advise us with how best the current structure should be amended in the service code. I wanted you to be reassured that we do in fact want to use OAuth2 bearer tokens.

Best,

Josh

On Dec 12, 2017, at 11:43 PM, Łukasz Lewczyński llewczynski@soldevelo.com wrote:

Hi Josh,

Thanks for response, I will start working on solution #1. I think for now there is also one more problem with this solution. We will treat the API keys as a service-based tokens and currently all those tokens (if endpoint support it) have access to everything. I know in the future those tokens will have some roles/rights assigned so the problem will be resolved in the future.

Regards,

Lukasz

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/1A011DE8-2B66-47CD-BFAC-8C70FDEC2E1F%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

On Wed, Dec 13, 2017 at 6:04 AM, Josh Zamor
josh.zamor@villagereach.org wrote:

Hi Lukasz,

I certainly envisioned #1 and not #2. Put another way, using access_token or the Authorization header field to transport OAuth Bearer tokens. I don’t think we should invent our own header fields or tokens here.

I agree that some additional checking would need to be added when checking the token - the kind of token we’re interested in are closer to what we’ve called service-based tokens rather than user-based tokens.

I look forward to seeing how this design could be made elegant. It’s more than okay here to start small: we know that a first pass for these API tokens don’t have options an administrator selects when creating them, it’ll just be for certain CCE endpoints. In the near future we’ll get to identifying specific types of API tokens that will hopefully align with specific services.

Best,

Josh

On Tuesday, December 12, 2017 at 3:38:03 AM UTC-8, Łukasz Lewczyński wrote:

Hi,

I am working on OLMIS-3135 / OLMIS-3784 to investigate if Spring OAuth could handle API keys somehow and because of that there will be less work to do by us.

For now I found two solutions to handle API keys by OpenLMIS:

1. Use access_token as a API key (most things are handled by Spring OAuth)

In this solution we will have a single entity in the reference data service - Service Account - which will contain fields like id, login and list of rights. The id field is required by database and the login field will be equal to access_token generated by the auth service which will be always valid (for now).

This solution if quite easy to introduce and don’t required too much work from us.

The problem I found with this solution is how service endpoints should handle new request type. Currently we only check if a request was sent by other service or by the end user. Probably, we will need to add a new if statement to check if the request was sent by an external service.

Also here we mix the meaning of access token because in some requests it will be treated as an access token and a API key in the same time. I am not sure if this is safe and correct approach.

2. Use custom header / request parameter (Some part will use Spring OAuth)

This solution requires more coding staff because we will need to create entities in reference-data and auth services (similar to user entities in those services), a custom filter to handle our custom header / parameter, probably custom authentication provider, and maybe some other additional classes.

In this solution an external service will use our custom header / parameter (probably X-API-KEY header or api_key parameter) to authenticate itself so our filter will check if there is a correct entry in the auth service, generate access token and add it to the request. In this case the external service will be authenticated with each request but only if the access token is expired. The access token part will be handled by Spring OAuth. Also if there will be an access token and the custom header / property the token will have higher priority than custom header.

Like I said this solution requires more coding but it would be easier to check a type of request by service endpoints because the principal field in Authentication will contain different values for different request types:

  • client id -> service request
  • username -> user request
  • service account -> external service request
    Also in this solution we don’t mix the meaning of access token. It will be always treated as an token that authenticate a user.

I would really like to hear what do you think about those propositions. If you think that there is a better approach which I don’t see then please let me know.

Regards,

Lukasz

Łukasz Lewczyński

Software Developer

llewczynski@soldevelo.com

**

SolDevelo** Sp. z o.o. [LLC] /
www.soldevelo.com

Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/b676d308-e4ae-4f17-ac65-f5a9c4fcd370%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

Paweł Albecki

    Software Developer

     palbecki@soldevelo.com