I'm new to both angular and web api, I've worked previously on asp.net web forms and java jsp's my question is since angular is pure js framework and web api is used for Http services ,if we build web applications using both these technologies how can session management be handled, can we create session in web api controllers ? If we can, since webapi (REST) is stateless does it violate the principle of REST statelessness , please clarify
Thanks
Angular and WebAPI do not change how to track session in web applications. Usually, this is done with a cookie that is sent with every request. Since cookies follow domains, Angular requests will always send in the cookie (just like they did before).
To answer each of your questions:
can we create session in web api controllers?
Yes, we can access session through HttpContext.Current.Session.
does it violate the principle of REST statelessness?
REST (Representational State Transfer) doesn't have a principle of statelessness. HTTP is a stateless protocol. REST says that calls to the server (using HTTP verbs etc.) should progress state of the application.
I don't have the reputation to comment in response to him yet, but David Tyron seems to be misunderstanding the term "stateless" in this context. Obviously, both the API and the UI using it have to maintain and progress data that can be properly labeled a state, but in the context of RESTful APIs, "stateless" is usually specifically referring to the fact that the API doesn't keep track of the client's state.
The idea behind this is that each request to the API must include all of the necessary UI information to perform the required action. In other words, each call must happen in isolation and independent from each other.
Sessions absolutely violate this principle, though it's probably the most common thing that is used that prevents something from being 100% RESTful.
(On a related note, Cookies still count as stateless since the client is the one responsible for storing that data.)
Related
I'm experimenting with these 2 technologies to make a secure web app [Currently learning React (60%) and Django (<50%). This is intended to be like a medical database, so doctors and nurses enters their patients' information. They need to login obviously. I wanted to implement React-based UI (And not using the classic method to create views from django), so I've found many tutorials just like this one:
https://www.digitalocean.com/community/tutorials/build-a-to-do-application-using-django-and-react
It basically turns Django into a restAPI, and then the React frontend uses axios to retrieve data from the endpoint. Sounds not bad at all (comparing to the native method of rendering data in a webpage from Django), but the problem is that I have no idea on how to make this secure, you know, Django provides an auth system, which is pretty good and secure, I have to say, but in a project with this structure, the auth needs to be done in React, so there many questions appear:
To start with, is it a good idea to make a project of this structure? (If no, then what could be a good one)
If it's a yes, how can I protect the API so only logged in users can interact with it? (What mechanisms to ensure protection)
Yes, this is absolutely a good idea to separate the client application and the backend server application.
You can access the backend through the rest api basically with any frontend framework/app/script.
Customers are able to extend their own applications with the abilities of your backend service.
You can create multiple different frontends that use the same backend or different parts of the same backend via the rest api (multi-branding, reselling). Or you can just swap the frontend framework every second year to a new one.
It's also easier to create different automations by using the rest api.
And the list goes on.
For django rest api auth I would recommend Token Authentication which is already included in the Django REST Framework and for React use this tutorial for implementing the login and the token handling.
And don't forget to use TLS on your servers, and create API documentation. (Example)
I have set up a Symfony based API which is being used by an Angular front end which is totally dependent of it (User registration included)
I have read multiple threads recommending using WSSE or FOSOAuthServerBundle but I'm not sure about the best method ?
If I understood correctly, WSSE has to send for each API request x-wsse headers which make me think it is not the best suited for performance.
About the FOSAuthServerBundle I have never used it and looks a bit complicated to me compared to WSSE, thus that's why I'm asking there before trying to implement it.
I have 2 simple groups of user (basic and admin), what would be the best way to secure my API, additionally providing an easy way to keep user persistence (I mean accesses through the different pages)?
How should it be in the Angular front side ?
Thanks for your help.
Refs: http://blog.tankist.de/blog/2013/07/16/oauth2-explained-part-1-principles-and-terminology/
http://obtao.com/blog/2013/06/configure-wsse-on-symfony-with-fosrestbundle/
It all depends on what your requirements are.
First of all, OAuth 2 is an authentication mechanism/spec which you can use in combination with sessions/bearer tokens/... This also applies for local accounts (since you want to do user registration).
FOSAuthServerBundle is a bundle to implement the server-side of the OAuth2 specification. This basically means you can expose your OAuth2 side of the API to other applications and allow them to use your accounts to authenticate. Think google login, twitter login, etc but for your own app.
This all has nothing to do with the way you validate / authorize your requests after the initial login has taken place.
Do you want to implement stateless authentication? Then I would recommend using the new JSON Web Token (JWT) specification.
See Symfony Bundle (LexikJWTAuthenticationBundle) and JWT description (JWT.io)
There are many resources on it from the angular side of things and the API part is pretty straightforward.
WSSE does not seem suited to implement in a RESTful API and I have no experience using/implementing it so I cannot comment on it too much.
I have Web application with angular as frontend and Django REST as backend.
My web application does the request like
/api/options/user?filter={}
Now is it possible that if those requests are made from application then they go through but they type that in broswer directly and edit some filters then they don't work
Although the data is not sensitive and they can still see it via console but i just don't want them to play with it or at least make it hard
You can't rely on the URL to distinguish between the two cases. You could have your application provide information in the headers of the request, which a browser would not know, but someone writing their own application could mimic your technique.
I've picked up Angular and am now developing two separate applications, the frontend, Angular app, and the backend, the Laravel app.
As of now my backend app is just an API endpoint that handles requests, database interaction, logic, validation, etc.
However, what stops someone from requesting /api/users/1 and getting that data?
Right now there is nothing in place that prevents this from occurring.
What's the best way to prevent this from occurring and verify the request is sent through the application and not through something like http://hurl.it from some random user?
You should first evaluate what routes need to be protected, and who should have access. Sometimes it might be fine to leave them open to the public.
Once you've figured that out you have a few options. I personally lean towards the oAuth 2.0 protocol. Some people find it to be over kill. Then there is also WSSE, I personally feel like today there is far better resources explaining the use of oAuth and would probably be easier to follow.
You can google around for oAuth server libraries for laravel. One such is: https://github.com/lucadegasperi/oauth2-server-laravel
You will also probably want to enable CORS if your angular app is on a different domain from your api. IE: api.example.com (holds api). And example.com is where your app lives.
For CORS laravel also has some packages, one such being: https://github.com/barryvdh/laravel-cors
I am designing a web app which has two UI - one a traditional web page(HTML views) and one a WPF app. I know that in order to have a Seperation of concern its best to design as shown below as in, a Web API that is consumed by a MVC app and a WPF app.
However I am a time crunch and I am wondering if I can get away with having just a traditional MVC design as below. Also I may have a lot more non-CRUD operations which if I were to go WebAPI ,will have to implement as RPC style, adding to complexity(more work,more time) of the webAPI.
My only question is - can a MVC action be consumed in a WPF app? And if yes, do I need to use any special API to do so as mentioned in this post or will the new HttpClient package suffice?
Yes a WPF application, just as any other application that is able to send HTTP requests and receive responses, is able to consume an ASP MVC controller action.
After all, ASP MVC framework just parses URLs, deduces routes information (area, controller, actions, parameters and so on), and finally invokes the associated action with parameters before sending you an HTTP response.
From MSDN :
In contrast, user interaction with ASP.NET MVC applications is
organized around controllers and action methods. The controller
defines action methods. Controllers can include as many action methods
as needed. Action methods typically have a one-to-one mapping with
user interactions. Examples of user interactions include entering a
URL into the browser, clicking a link, and submitting a form. Each of
these user interactions causes a request to be sent to the server. In
each case, the URL of the request includes information that the MVC
framework uses to invoke an action method.
So even a simple HttpClient would be enough to interact with an ASP MVC controller action.
But you can also use a framework or library of your choice that help you to build HTTP requests and/or to transform HTTP responses into something more suitable for your application.
It's not mandatory but it could make save some time!
That being said, beware of all scenarii requiring authentication, it could get things harder :
If you need forms authentication, then you can to retrieve your auth
cookie first, and then include it in future HTTP requests (see
this post for more information)
If you need windows authentication, then you have to provide your credentials (see this page from asp.net website)