This means that web,ios,android is just a presentation layer, and persistent operations are lost to the API.
Let's not consider the template rendering this piece, we might put this piece on the front end.
The current tangle is the web session and app token problem.
This API is not only verified by token, but when the Web request is that he will have a user session.
When a user session is included, the token is not verified.
Is there any limitation or disadvantage to this practice?
Welcome to shoot Bricks!
Back-end PHP.
Reply content:
Of course, and I have a lot of success stories, the industry should have a lot of cases, although some are bluffing, and some just seem to be so, actually not.
But then again, it's up to you if you have a senior architect, and if you really have a lot of money, I don't mind.
with. NETTo show you the viability of this architecture. (PHP no Love Sorry)
If you really have a problem with the token and the session, either because you don't have the ability to deal with the architecture, or if you haven't played your heart, I don't know which one, and the answer is yes. I understand what you're talking about. Nobackend is a traditional architecture that does not want to take a technology like PHP or JSP, which puts a heap of user business in the session, and writes logic on the server side to update the page or manipulate the backend service (for example, update the database).
In my personal experience, you can put the page update and the user's current state on the front end, the backend API is a set of stateless services, which is a very common architecture.
The more troublesome (as can be seen from your problem description) is the security piece.
Native's client, you can consider the OAuth implicit grant type, which is the token directly placed on the client, because the native app is considered more secure.
In the case of the Web, token is more dangerous to direct the client, but the traditional method (including OAuth authorization Code grant type) is to place tokens in the session.
In fact, there are solutions to this problem. But you'd better ask yourself first, is there really no session? In fact, the session is generally difficult to completely remove, in terms of the overall system architecture, you are only in your programming vision without it. Reasonable use, and no, do not engage in fundamentalism. If only token is placed in the session, in case the server crashes, assuming that your application is handled well, the front-end business state can be persisted, it is simply to let the user log back and then return to the page just continue. For example, the online mall, the user just put things in the shopping cart, the background collapsed, but also just re-login, your shopping record is still in, you can continue to operate. This is a rough description, and the specifics should be based on the business needs, but I mean you should be able to understand it. You can read this post:lift, state, and Scaling
, irrelevant language. It can be thought that you may need to build a lot of wheels yourself, because a lot of things in the front end do not have mature tools, and finally slowed down your business. In simple terms,
1. Backend provides rest API, provides a/verify for login verification, and subsequent operations need to be accompanied by verification information
2. Front end through Ember/angular made WebApp, using AJAX consumption Rest API, I actually do not use cookies, every login is, because you are already webapp
3. If the need for safety on Https,cookie this thing I personally feel that can be exempt from the direct use of the JS API, authorization issues are difficult to solve, secret can not download to the browser, can only use implicit authorization, but most services are not supported ... A no-end scenario? This has been. There are quite a few cases in memory.
No back end is not really no backend, API implementation is not the backend and other technologies. Development to now should have basically no difficulty. The problem with the main question may be that there is no recognition of the difference between server token and Web session. Actually fortunately, and the interface server communication is certainly the Token,web end of the session must first verify that the service-side access is generated by the web side.
Let's take a look at the process,
User Login As an example,
1. User login, send authentication message to API server
2. Server Authentication OK, return a token to indicate validation through
3. Create a login session record the token acquired by the current login in the Web side
4. Login complete, jump to Application page
After the above, the user should look at TA coupon information
1. Take the token and username stored in the web-side session and call the coupon interface
2. Return coupon Information
The server did 2 things in the process.
1. Verify token legality (presence, expiration, source, etc.)
2. Legal, call the service return coupon information, on the contrary, error.
Here, you can see the session is the web-side presentation layer, token is the interface server session, clear level, it is clear.
