Skip to main content
Commonmark migration
Source Link

I am currently developing a simple web-based application that consists of various layers:

Model Layer

###Model Layer PerformsPerforms simple CRUD operations and provides access to the databes. Implements functions such as get_invoice(), create_invoice(), edit_invoice() and so on.

Service Layer

###Service Layer ConsolidatesConsolidates operations such as pay_invoice(), cancel_invoice(), and so on. The service layer is meant to be used by the various presentation layers in single, concrete actions. To do this, it may use more than a single model to accomplish something.

Presentation Layer

###Presentation Layer ComprisedComprised of controllers and views, renders the results and generates forms. The catch here is that there may be more than one presentation interface-- the application boundary lies at the service layer:

  • Web-based UI
  • API
  • CLI (command line)
  • iOS app

The question

##The question TheThe app must control who can access what at all times. To do that, I am adding security checks and authentication directly in the service layer. That way, a call to pay_invoice() will always check if the given user is allowed to perform that operation.

Is this correct? Should I be requiring every call to the service layer to be associated to a user ID and a set of permissions?

This seems straightforward for write operations like paying invoices. However, how do I go about implementing read operations? For example, a user might not have access to all invoices, but some background tasks might need that info from the service layer.

Another example is that a user should not have access to a full list of other users, but might need to have a dropdown list with just names (to assign a task, for instance).

It is worth noting that the app also provides public access to some data, like the login page or viewing an invoice PDF (no session yet). What happens in those cases? Should I create some sort of guest access to feed the service layer with?

In summary:

  • Is it correct to require a valid user at the service layer?
  • Would I need to add another layer in front that separates operations from user-based actions?
  • How should public access queries be treated?

Any specific reading on this is appreciated-- I haven't found much.

I am currently developing a simple web-based application that consists of various layers:

###Model Layer Performs simple CRUD operations and provides access to the databes. Implements functions such as get_invoice(), create_invoice(), edit_invoice() and so on.

###Service Layer Consolidates operations such as pay_invoice(), cancel_invoice(), and so on. The service layer is meant to be used by the various presentation layers in single, concrete actions. To do this, it may use more than a single model to accomplish something.

###Presentation Layer Comprised of controllers and views, renders the results and generates forms. The catch here is that there may be more than one presentation interface-- the application boundary lies at the service layer:

  • Web-based UI
  • API
  • CLI (command line)
  • iOS app

##The question The app must control who can access what at all times. To do that, I am adding security checks and authentication directly in the service layer. That way, a call to pay_invoice() will always check if the given user is allowed to perform that operation.

Is this correct? Should I be requiring every call to the service layer to be associated to a user ID and a set of permissions?

This seems straightforward for write operations like paying invoices. However, how do I go about implementing read operations? For example, a user might not have access to all invoices, but some background tasks might need that info from the service layer.

Another example is that a user should not have access to a full list of other users, but might need to have a dropdown list with just names (to assign a task, for instance).

It is worth noting that the app also provides public access to some data, like the login page or viewing an invoice PDF (no session yet). What happens in those cases? Should I create some sort of guest access to feed the service layer with?

In summary:

  • Is it correct to require a valid user at the service layer?
  • Would I need to add another layer in front that separates operations from user-based actions?
  • How should public access queries be treated?

Any specific reading on this is appreciated-- I haven't found much.

I am currently developing a simple web-based application that consists of various layers:

Model Layer

Performs simple CRUD operations and provides access to the databes. Implements functions such as get_invoice(), create_invoice(), edit_invoice() and so on.

Service Layer

Consolidates operations such as pay_invoice(), cancel_invoice(), and so on. The service layer is meant to be used by the various presentation layers in single, concrete actions. To do this, it may use more than a single model to accomplish something.

Presentation Layer

Comprised of controllers and views, renders the results and generates forms. The catch here is that there may be more than one presentation interface-- the application boundary lies at the service layer:

  • Web-based UI
  • API
  • CLI (command line)
  • iOS app

The question

The app must control who can access what at all times. To do that, I am adding security checks and authentication directly in the service layer. That way, a call to pay_invoice() will always check if the given user is allowed to perform that operation.

Is this correct? Should I be requiring every call to the service layer to be associated to a user ID and a set of permissions?

This seems straightforward for write operations like paying invoices. However, how do I go about implementing read operations? For example, a user might not have access to all invoices, but some background tasks might need that info from the service layer.

Another example is that a user should not have access to a full list of other users, but might need to have a dropdown list with just names (to assign a task, for instance).

It is worth noting that the app also provides public access to some data, like the login page or viewing an invoice PDF (no session yet). What happens in those cases? Should I create some sort of guest access to feed the service layer with?

In summary:

  • Is it correct to require a valid user at the service layer?
  • Would I need to add another layer in front that separates operations from user-based actions?
  • How should public access queries be treated?

Any specific reading on this is appreciated-- I haven't found much.

Source Link

Adding authentication and filtering in the service layer

I am currently developing a simple web-based application that consists of various layers:

###Model Layer Performs simple CRUD operations and provides access to the databes. Implements functions such as get_invoice(), create_invoice(), edit_invoice() and so on.

###Service Layer Consolidates operations such as pay_invoice(), cancel_invoice(), and so on. The service layer is meant to be used by the various presentation layers in single, concrete actions. To do this, it may use more than a single model to accomplish something.

###Presentation Layer Comprised of controllers and views, renders the results and generates forms. The catch here is that there may be more than one presentation interface-- the application boundary lies at the service layer:

  • Web-based UI
  • API
  • CLI (command line)
  • iOS app

##The question The app must control who can access what at all times. To do that, I am adding security checks and authentication directly in the service layer. That way, a call to pay_invoice() will always check if the given user is allowed to perform that operation.

Is this correct? Should I be requiring every call to the service layer to be associated to a user ID and a set of permissions?

This seems straightforward for write operations like paying invoices. However, how do I go about implementing read operations? For example, a user might not have access to all invoices, but some background tasks might need that info from the service layer.

Another example is that a user should not have access to a full list of other users, but might need to have a dropdown list with just names (to assign a task, for instance).

It is worth noting that the app also provides public access to some data, like the login page or viewing an invoice PDF (no session yet). What happens in those cases? Should I create some sort of guest access to feed the service layer with?

In summary:

  • Is it correct to require a valid user at the service layer?
  • Would I need to add another layer in front that separates operations from user-based actions?
  • How should public access queries be treated?

Any specific reading on this is appreciated-- I haven't found much.