We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Micro Phalcon, REST API, secure it

Hi,

I'm a begginer on Phalcon,

I'm writting an AngularJS application who communicate with a Micro Phalcon application (a simple REST API). Everything is OK.

Now I want to secure this REST Api (because it's a private administration app). It's already in SSL.

Can you give me tutorials to do it ? I'm lost and I never do this before.

Thanks in advance.

Are you a beginner with server-side coding? If yes, then look up the concept of user sessions.



1.3k
edited Jun '15

Thanks for your response,

I'm not a begginer in backend, just in REST security.

I'm not agree with user sessions :

RESTful: One can characterise applications conforming to the REST constraints described in this section as "RESTful".[15] If a service violates any of the required constraints, it cannot be considered RESTful.

stateless constraint: We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

I'm just a begginer with all term of security : OAuth, JWT... and don't find a simple way to implement it.

What that's referring to is using something in the session to affect the response. Storing something like the page number in session and not requiring that to be passed with the request, would be violating the stateless constraint. You can still use sessions to store identification information - just not any information that is used to determine the response to the request.

For example, upon login you can assign a session ID to the person. That session ID should then be passed with any RESTful request to identify the user as authorized. This is the same as submitting an app or user token to a RESTful API.

The session ID is not "information necessary to understand the request", its information necessary to determine if the request should be answered.