I am writing the spec for a complex business solution; it is basically a set of web apps that are all on their own servers. I want them to be independant so if one has a problem or becomes very busy then the rest are not affected.
There will be a central server that will act as the payment gateway for the apps as well as providing data to the apps themselves. The data is minimal; user ids, have they paid for that app etc.
The idea was that when an app was purchased then we'd just pass that data to the app in question.
The question is how to do this while not holding up the user's experience while we wait for the app server to resoned. The idea was to enter it into a queue and process them one by one on a cron job. However there are concerns that this will not be fast enough and the user could have to wait before accessing the app.
The other idea is that the app just contacts the main server when the user tries to use it. The main server can then approve the user and this will be kept on the app server DB so it doesn't have to check again.
What do you all think about these ideas? Is there an obviously best way of doing it?
The system should be able to scale to 100+ apps and tens of thousands of app purchases an hour.
Very interested to see what you all think! Many thanks
I have a similar but slightly different situation here, supporting a potential competitor... have I gone mad?? haha
To the topic, we use cURL to connect the server requests generally, especially if we don't want information to be public, we have a specific VPS set up for payment handling, account functions and financial functions, this will post to a centralized mySQL database for access information only so it will support a single sign on for multiple apps on multiple server clusters.
To ensure the user is immediately moved to the app they want and it works correctly, we use cURL to post initial data creating the default records in the specific app database, we then set up a PHP header redirect using to move the user to the app requested with the single sign-in already working as part of the cURL post preformed earlier.
An access key is important to us as it enables the single sign-on to be secure. It is generated 1 time per account and never updated even though we can if there is ever a security violation. We then use cURL in the user auth process to ensure the user is still signed in using their key and user id. The key is never actually passed publicly but always posted server side using a cURL method hiding it in the PHP.
I hope this helps.
Related
I'm planning on creating a multi-page web app using Laravel as a back-end REST API and a Vue.js front-end to consume this API.
To be clear up front, I'm not interested in code snippets of exactly how to set this up, unless some will help visualize the architecture.
What I would like to know is how this 'Split-Stack' can be deployed in a completely separated manner. I.E. neither stack shares a codebase, and are stored in completely independent repositories.
I'm not very familiar with JavaScript frameworks beyond jQuery, so I think my lack of understanding lies mainly in the Vue.js department. Some questions which stand out in particular are:
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
After reading many blog posts, it is obvious that this architecture is possible, but I'm struggling to find details on how exactly this is configured to be completely separate.
The tools and technologies don't necessarily matter here, but any specifics for Vue.js and Laravel are appreciated.
I have a VueJS Front-End set up with an ExpressJS Back-End, which is very similar to what you are talking about. And yes, it is entirely possible. So let's take a look at each of your questions individually.
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Yes, when you run VueJS, you can either build it as a static application or serve it as a NodeJS Application.
See the Deployment section of the Vue CLI 3 documentation here. It explains how the /dist directory is used to serve the VueJS Application in the manner you are intending to.
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
I recently posted an example of how to host both your Front-End and API on the same server here. (Includes Coding Examples and Explanation). This answer references ExpressJS as the API, but the principles are the same. Really, just have your Front-End listening on port 80 and have your API operating on a different, unused port (ie: 8081).
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
I handle all authentication on the back end. Basically, in the Vue Router, you can set a secure parameter. Then declare a router.beforeEach((to,from,next) => {}); call towards the end. This call should then check to see if the user has a valid login token and redirect them to the applications login page after setting a cookie with the URL the user was asked to login from so that they can be sent back to it after logging in.
In our case, we have the user redirected to the VueJS Route /saml/login. The /saml/login component. This component makes a call to the API and returns the address the user should be redirected to to login. In our case, it is the API (which is running on the same server, but a different port [see answer above]), www.example.com:8081/api/v1/saml_login. This then works with the IDP and receives the token and user data. This is also where you would perform you ACS functions (provisioning the user, updating the login time or user data, etc.) After receiving the token, it is placed into a cookie or other placeholder so that it can be used to validate against the token stored in the Database when the user was validated initially. (It is a best practice to set expiration's on your tokens). The user is then redirected to the url stored in the cookie that lets us know where they were asked to sign in from so they can view their content without having to look for it again. (Happy to share code on this if you want)
I think using Firebase or Auth0 Authentication is one of the best ways to do this. Firebase or Auth0 will take care of all the authentication for you and allow your backend to verify the authenticity of your front end. So that makes it much easer to separate the two.
There is an admin SDK for connecting Laravel to Firebase and there are templates and existing authentication SDK's for Vue. There are a few articles which sort of describe it but I haven't seen anything that pieces it all together yet. I was able to figure it out from 2 or 3 different articles and it ended up being easier than I thought it would be.
I have to make an application that receives commands from a website and therefore perform an action.
I thought about creating a login in android to send the username and password for POST and if this is correct, the web server will return a unique token. That would serve me later to send information to the server and ensure authentication...
But ... how can my android application know when the website has a warrant for?
I've thought about that all the time is pending a URL "checkOrders" and if it finds your token, request orders to another URL
Anybody know other method to make it?
If I understood your question correctly, the only (battery and otherwise) efficient way is using push notifications. Unfortunately, this approach is not even close to being simple.
Since you're developing an Android application, you may want to consider Google Cloud Messaging and Parse Push. If you're planing on developing apps for iOS and Windows phones in the future, I'd strongly recommend Parse Push. At the moment, it's free for up to one million users.
Hyperlink for GCM will lead you to generally useful reading on this topic. That's why I am not elaborating here.
My iOS app needs to connect to a mysql server. To accomplish this, I'd like to create a webapp that acts as the middleman between the client side apps and the server side database.
My concern is that someone can simply figure out the URL that my app uses and pass their own URL parameters - and since the webapp has no idea whether legitimate data is being sent from my iOS app vs. someone just typing in the properly crafted URL from any web browser, the system will be vulnerable.
Let's say I have a PHP function for marking a user as "verified" (after I send them an email verification code). This is pretty standard stuff, but what's stopping someone from making the same request from a web browser?
Of course, the user that the app uses to make database queries will have limited privileges, so the rest of the database won't be at risk. However, even having users activating their accounts from outside the app would be catastrophic.
The option that I thought of was using https so that even if the user figures out the URL, they won't know the password and wouldn't be able to sniff it since it's encrypted from start to finish. Unfortunately, https can be expensive for a poor college student, so I'd like an alternative if one exists.
As stated before, there is no 100 % security possible. But there are several solutions that put together give great security.
Https
As you point out, this is an important part , as it prevents sniffing.
Sessions
Use sessions and don't allow any request without a valid session ( except the first, that must authenticate the app ).
Fingerprint
Check the user agent and set extra http headers, to get a fingerprint unique to your app. ( Still someone could sniff, but he needed to use curl or similar. )
Obfuscate requests
Build your query string and apply a hash function. The server needs to implement the reverse function. ?43adbf764Fz instead of ?a=1&b=2
Encrypt
This goes a step further. Use a shared secret to calculate a hash. On the server repeat the same. This is already strong security. In order to break, one needs to reverse engineer your app.
Use unique shared secret
You say it is a app for iOS. Upon installation a unique token is generated by iOS. Have your app register this token with your server. Like this you have a strong shared secret unique to each installation, and there would be no way to hack your web app.
I am looking to build an API that I can deploy on my servers to monitor system load.
It will report to a central manager server that runs a client to display the information.
The issue I am struggling with is best to secure the API.
What I want is for the client to be the only software that can access the server and retrieve this information but I am unsure how to achieve this using PHP.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The client is also written in PHP using MySql and has a secure login.
This sounds like you're trying to solve the wrong problem.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The only right answer to this is authentication. You need to protect your API by giving each user access credentials known only to them.
Your API must never reveal any data that the client isn't allowed to see as per their authentication credentials. Trying to work around this danger by trying to somehow protect the client from prying eyes is not safe - somebody who has access to the client and can observe it running will be able to reverse engineer any traffic between it and the server given enough effort.
If the API is properly secured, it won't matter to you which client tool is used to access it. The requirement to limit API access to a certain program will go away.
if you use SSL, along with authentication (i use 3rd party auth google, fb, etc), create data /reports on the fly and have the data saved in a subdirectory OUTSIDE your web folder (instead of /var/www, /var/myStorage/currentSessionId/), then you basically guarantee the security that you want.
your php will only access a subdir that is named for the session it is running under.
I'm working on integrating a Magento store with an existing desktop Point of Sales software. My idea is that this desktop program would connect through Magento's REST API to gather the product list, inventory changes, etc., and it will also commit new products and other updates through the API endpoint.
The problem arises when I don't want the person in charge of the PoS know the API credentials or don't want to bother prompting for them. The best would be to set them up in a config file.
I thought about loading the API authorize page in the background and automatically post the credentials to the login form. But this looks like a nasty approach.
Any ideas?
Not a solution but some words of experience in this matter...
Magento's API can be slow and the user will wait forever for the task to finish especially if the server is under load. We use another application which uses the Magento's SOAP API which I built using java to handle all updates/downloads between magento and our POS. This way the user is not waiting on slow responses, or stopped by loss of connectivity.
We have adopted your queue approcach, and another reason for having 1 application with a queue is that it handles all updates from all users and Only Allows 1 Task To Execute At Once. You need to do this to avoid database locks. e.g. Two users modify a product and you get a table lock error and the update fails. You can also overload the server by flooding it with lots of single user requests to the server. We still have event driven processing as opposed to synch scripts by having our POS send messages to our local app instructing the app about the task and it simply queues the task for processing. Our application has no user interface what so ever and I run it as a System service on our server, with the user credentials stored in a config file.