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)
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'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.)
In this link: http://www.sencha.com/blog/spotlight-ext-js-customers/
Please scroll to the section :Why We Chose Ext JS
There is this line :
By using Ext JS, we lowered the cost
of developing a Web services API.
But I do not really get the explanation. How cost of developing a Web services API can be lowered by a client side framework?
I don't think the explanation conveys what the author intended. I think they were enthusiastic about ExtJs's AJAX APIs, which are easy to work with and can be called using a number of GUI components (which they mention).
The AJAX and component APIs do not create a server-side Web service API for you though, which their testimonial leads you to believe by saying:
This gives us the benefit of exposing
these same AJAX (JSON) calls, as a
Web services API, to our customers...
By using Ext JS, we lowered the cost
of developing a Web services API.
Well not quite, ExtJs doesn't create a Web Services API for you; it creates a method of interacting with your custom REST (or whatever) API. Although maybe they meant that since ExtJs defines how the client should interact with the server, via their numerous components, their server-side services were easier to create. For instance, ExtJs makes it easy to work with REST webservices, and it defines expectations in callbacks, etc. So in ExtJs providing the client solution, it was easier to devise a server solution (the webservices API) given half of a contract.