When it comes to building my web applications, I know HTTP 2 is going to be recommended for all traffic coming to the site. I understand the security concerns and the reason why it is recommended/forced to be used now.
When it comes the web-based languages I code in and understand such as Ruby, PHP, and Perl.
Is there any special functions that I will have to do to produce a secure connection to my server or all do we need to do is redirect all traffic to https:// over http://?
Basically, my autoloading class in PHP would load all classes and functions for my web application to operate. Would I need to create a SSL.class.php for allowing the connection to be secure within my PHP?
The changes in HTTP/2.0 over HTTP/1.1 are mostly relevant if your application streams large amounts of data to many simultaneous users.
Is there any special functions that I will have to do to produce a secure connection to my server or all do we need to do is redirect all traffic to https:// over http://?
No. HTTP/2.0 does not require TLS. If you want TLS (which, personally, I encourage), you still need to send clients to https://.
Basically, my autoloading class in PHP would load all classes and functions for my web application to operate. Would I need to create a SSL.class.php for allowing the connection to be secure within my PHP?
In most cases, the HTTP layer is a webserver problem, not a PHP-land application code problem.
If you are working on a framework that insists on parsing request headers and managing responses in a very HTTP-like fashion, then yes, you probably need to be aware of some of the changes in the new version of the protocol.
Differences Between HTTP/1.1 and HTTP/2.0 for Developers
Servers can push more data over an established connection in HTTP/2.0. This is really neat if you need to push real-time notifications (e.g. what StackOverflow does).
Better multiplexing and streaming; it's now possible to stream multiple resources over the same HTTP connection.
Source
Unless your application is keenly aware of networking protocols, it shouldn't matter much for our day-to-day CRUD interfaces.
Related
I'm in the process of developing a system which is heavily dependent on a web service which is designed according to REST principles. The connection is over HTTPS, and my issue is finding a good way to identify clients. There are several users from several different companies with several different access levels.
The backend/middleware is written in PHP, and up until now, I have used the $_SESSION to identify users.
After reading more about REST services, I learned that REST services should be stateless and every call should provide all information necessary to handle that call. I interpreted this in the direction that the server should not maintain any states related to specific clients.
Questions:
Does this mean that using $_SESSION[some_identifier] to preserve state between calls is not aligning with the REST style?
I'm now considering using a "short-lived token" logic instead. This token is exchanged with the server on each request, and the server provides a new token in the reply of each request. Is this approach more RESTful?
You should be using the Authorization HTTP header, used by various HTTP authentication systems such as Basic, OAuth2, or your own proprietary extensions.
I want to create following project :
Server application hosted on Azure - it connects to databse via Entity framework and gives and API for anyone who want to connect (but with account stored in SQL database)
WPF application - it consumes server methods, objects etc.
Web app (php & javascript) - also consumes server methods and object etc.
IMPORTANT : I have only azure student's subscription and I want to hold onto it - buying anything else is out of the question unless it has strong argumentation.
I figured that to do this I have to create REST Web API because I have no other choice to connect to server than via HTTPWebRequest (because I want to have the same API for WPF nad web app).
My question is : does better solution exists?
I think I can create different API's for desktop client than web app but I have no idea how to do that. Whould you be so kindly to show me other way?
Why dont I want to have this solution?
Reason is simple. For big databases and slow internet connection it would take ages to download whole data in few seconds. As far as my knowledge goes there is no lazy loading in REST thus my WPF application's thread reponsible for downloading database would freeze for a big period of time.
If my question is too broad please leave a comment before you put up a flag.
Also, any tips regarding my project design are well appreciated.
Different APIs for Desktop and Web: this can be done easily enough. Assume you have a class library to contain your business logic (domain stuff). Create a web api project that makes use of it, then create yet another web api project separately that also makes use of the core models. When you deploy, deploy each separately to a different domain/subdomain (I'm unsure if you'll require further Azure resources for this, but consider api.desktop.myapp.com and api.web.myapp.com... no real technical reason why you can't do it that way, though for architecture reasons I'd avoid it (it's really coming close to if not definitely is duplication of code).
Same API for Desktop and Web: you stated that you thought you'd have to do this differently for the desktop and web, specifically because of the resource usage on the server. I disagree here, and think you should implement some standardized rate limiting into your API. Typically this is done by allowing only X amount of resources to be returned in a single call. If the initial request asks for more than X limit, an offset/nextID is returned by the API, and the client submits a new request noting that offset/nextID. This means you have subsequent calls from the client to get everything it needs, but gives your server a chance to handle it in smaller chunks (e.g., check for rate limits, throttling, load balancing, etc). See the leaky bucket algorithm for an implementation that I prefer, myself: https://en.wikipedia.org/wiki/Leaky_bucket)
I have developed an Ubuntu desktop application to monitor when computers are on that is currently writing directly to a MySQL database. For security purposes I assume that I don't want to have all of these clients talking directly to my database, and instead need to create some other web interface between the client and the database. Should I write this interface in PHP? How does the client invoke this interface?
For security purposes I assume that I don't want to have all of these clients talking directly to my database
Probably not. You can lock down the database to some degree, but probably not enough.
instead need to create some other web interface between the client and the database.
Web services are the usual way to provide a controlled interface to a database these days.
Should I write this interface in PHP?
You could. Language should is a fairly personal thing though. I'd probably go with Perl's Dancer framework myself. It is capable of handling a RESTful API (although that guide assumes you've already learned the basics of Dancer).
How does the client invoke this interface?
By making an HTTP request. It might be as simple as a POST request with on as the body (and then the server uses the client ip address to determine which machine the request came from). The specifics of how you go about that depend on the language you are writing the client in and the libraries you have available to it.
Here's the situation:
I have a web hosting which provides a MySQL database account, but connection only allows from localhost.
I'm considering to expose this MySQL through web interface, and extend the mysqli class so I can normally read/write to this database from another host.
Before doing this, I want to know if my solution is a good idea, and whether there already has such an open source solution to my situation?
Use Web Services. Web services are designed to provide an API so that one server can communicate with another server to access the resources of that server. The advantage of creating a Web service wrapper around your MySQL database is to avoid exposing the SQL layer to the broad Internet.
In general, by writing Web services, your application can only use the services that you've specifically chosen to expose. Additionally, many Web service frameworks offer authentication packages and validation that can help prevent malicious entities from illegally accessing or manipulating your data.
Finally, should you migrate to a different data source, you can maintain the same uniform interface between the application and the datasource, which eliminates the need to modify the PHP application.
However, by directly exposing your database to the Internet, you potentially expose yourself to data theft and data loss.
For more information on Web services, you could start with this Wiki Article on REST.
That's a lot of overhead and reimplementation work. Instead consider to open the MySQL server up for remote connections, using SSL and certificate authorization: http://dev.mysql.com/doc/refman/5.1/en/secure-basics.html
This allows you to expose the real mysqld server. You will need to use the most recent PHP version, as that adds SSL support in the PDO interface for example. http://www.php.net/manual/de/ref.pdo-mysql.php#103501 But I'd say that's still easier than crafting your own RPC interface and securing that.
And if you actually use Mysqli, then the SSL/cert support is already built-in: http://php.net/manual/en/mysqli.ssl-set.php
Here is a good place you can get started to creating an API.
First, you should evaluate the kind of data you want to share across your servers and see if you really need it.
I'm choosing between AMQP (RabbitMQ) vs XMPP (eJabberd) for my browser-based flash-free javascript powered real-time turn-based game. I don't know much about AMQP and XMPP protocol. I would like to use PHP for user-authorization and some data store-retrieve with MySQL. As far as I found out, RabbitMQ has PHP clients but eJabberd not.
What I understood is javascript client calls PHP script and manipulate necessary processing and then pass to AMQP or XMPP server to pass the data to opponent player. There is a good book 'Pro XMPP Programming with JS and jQuery' from Wrox but there is no example with PHP. So following are my questions.
1) Which protocol is suit for my game?
2) Shall I choose RabbitMQ just for it's PHP client support?
I've had fairly good success implementing an XMPP client in Javascript by using HTTP Bind approach to XMPP BOSH. I don't know about AMQP, but for client-side access, I love XMPP. A few words why.
ejabberd already includes BOSH support, and to use with Javascript (and presumably Flash) you just need to direct your server to redirect requests to port on which you configure ejabberd to listen for HTTP requests. (And even this only because Javascript security model in today's browsers forbids Javascript requests to different domains and even different ports.)
Since XMPP is a bunch of quite trivial small XML documents, it should be fairly easy to encode them in any language you pick.
Since it's widely supported, you might be able to avoid requiring your users to register with your service, which they will most certainly appreciate.
Implementing XMPP means you can trivially add instant messaging support to your game, with federationing to the rest of the Jabber network (including Google Talk).
Since I don't know anything about AMQP, I cannot compare them -- but I can say why I'll always first consider XMPP for my future multiplayer projects.
My personal reason for choosing ejabberd is simple -- it's super easy to install and configure on Debian. I'm almost completely unfamiliar with Erlang and Java; what I understand, however, about Erlang is that it makes scalability easy to achieve, and ejabberd people say they have achieved it.
If you want to do server side logic checking, I'm afraid I don't know of any good method. I'd go with a proxy PHP script doing sanity checking on the incoming XMPP BOSH message, then forwarding it to the server, instead of just forwarding it via Apache's mod_rewrite.
As mentioned above, you will definitely have to do proxying of some sort (with mod_rewrite or with PHP or in some other way) since the XMPP server will listen on a different port than the "main" web server, and Javascript cross-domain security model does not allow doing XMLHTTPRequest on a different port.
So, sanity checking might be easiest done while relaying BOSH requests to XMPP server of your choice. Digging into the server software might not be the best way to do this type of checks. It would take long, and would probably make it harder to integrate with the rest of your game.
Alternatively, I stumbled upon an answer that mentions XMPP components and ejabberd modules. This will be an interesting read for me, too.
Good luck, and be sure to drop a comment with the name of the game when it's done -- I'd love to see it :-)
I just noticed someone else posted a very similar question to yours. Its answers contain some more interesting info for you.
On using XMPP with Flash:
You could nevertheless use HTTP binding (BOSH) with Flash. In fact, while HTTP binding allows Javascript to access XMPP, it was conceived for a variety of applications, such as mobile connections that can often break.
I mostly figured out how to establish the connection by observing communications between web-based client JWChat and ejabberd (for info on BOSH), and then communications between cross-platform client Psi and ejabberd (for info on protocol itself). With JWChat and WebKit's Web Inspector or with Firebug for Firefox, one can easily track XMLHttpRequests being done towards the server. With Psi, one can turn on the XML console and read the communications log. Combined with prototyping a client in a language of your choice, studying BOSH and XMPP turned out to be very easy.
Also, following XEPs are useful: XEP-0124, XEP-0206.
O'Reilly book that I'm reading right now, "XMPP: The Definitive Guide" (P. Saint-Andre, Kevin Smith, Remko Tronçon; much cheaper on Apple's App Store) also gives you the feeling "why things are done the way they are", and documents many small things and various applications of XMPP.
After that, implementing a BOSH-based client could turn out to be rather easy. I have no experience with coding with Flash apart from making a button play and pause, so take this with a grain of salt :-)
As someone mentioned, you need to consider the client-to-server part; that seems of more importance.
It sounds like you already have the best book on the subject (Jack Moffit's XMPP + JS book) and I would definitely say that's the technology to go with.
Also you get user authentication, encryption and all the many XMPP protocol extensions on top of that, as the book will describe.
Even although I can't recommend any PHP-XMPP clients, I don't think you'd necessarily have the same level of features out-of-the-box with AMQP.
Also, if you're versed in other languages, and depending on the amount of game logic required, you could write an XMPP server component. See this prior question about XMPP + gaming for info:
XMPP C# Interaction
AMQP has not yet reached version 1.0 and has some possible design issues around it. There are XMPP clients for PHP so if I were you I'd give that a try first.