Snap! Websites
An Open Source CMS System in C++
The controlled_vars library allows you to define variables that you never initialize. This is very practical if you have a large number of variables or a large number of objects of a class.
The idea is pretty simple and once you remove the debug, the variable becomes 1 to 1 equivalent to a char, unsigned char, signed char, short, unsigned short, int, unsigned, long, unsigned long, etc. In other words, it goes really fast.
However, in debug mode, the class adds a bool to know whether the variable was initialized or not. If not yet initialized, you cannot read the value or you get an ...
The Hidden widget is used to include data in a form that has to be hidden. The concept is pretty simple, it allows us to have a session identifier in forms without having to show that identifier to the end users. The form session identifier is necessary to allow the saving of the data in the form. Otherwise we assum that a hacker is trying to send spam to the server.
In standard HTML forms, one can use an input typed "hidden". Many people make use of those to carry data on the client side instead of the server side. We strongly suggest that you instead make use of the user session ...
The following shows you a UML like graph of the current editor.js implementation. Click on the figure to see a full size version. The original file (editor.odg) can be downloaded as an attachment (see below).
Although we want to include similar features mainly in the Editor feature [core], it is probably easier if the Media support is presented as a separate feature to make it clearer in the documentation.
The editor should be capable to make use of the HTML 5 extension and allow video and audio directly in a website. However, this may not always be a good option for you in case you do not want (do not have) to offer the type of bandwidth that such requires you to have to provide videos and sound tracks directly on your websites.
The HTML canvas will be used to offer the Image Editor feature [core].
The OAuth2 implementation on Snap! Websites makes use of a GET to log an application in, and a GET to log it out.
The Log In feature makes use of the Snap-Authorization header field which is 100% copied from the Basic Authorization. We use the name Snap-Authorization because Apache2 does not forward the Authorization header field to Snap!
GET /user/oauth2 HTTP 1.1 Host: snapwebsites.org User-Agent: Application 1.0 Accept: application/json;q=0.7,application/xml;q=0.5 Snap-Authorization: Snap <base64 from "identifier:secret">
The OAuth2 module gives users two ...
Since the Users plugin has a secure way1 to authorize access to a Snap! system via a browser, offering such an access via OAuth2 is a very easy to implement extension.
The concept is very simple. Applications that want to access our services can do so using special URLs. However, anything that require the user to have permission generally necessitate a user to be logged in. Therefore an application that wants to manipulate data also needs to be logged in.
The application will make use of ...
Right now, each plugin infers a certain number of defaults for its settings and also it installs various defaults in the database when it makes it easier to deal with the values that way.
This creates a default Snap! installation template which does not automatically serve a user well because the resulting website is likely going to look quite raw.
The Snap! library and several of the core plugins offer a mechanism to make the installation of all the other plugins data a breeze. That data is expected to be defined in a content.xml file which is loaded the first time the plugin is loaded and ...
As we are working on Snap! Websites we run in various problems, one of which is the installation process and later the upgrade of a cluster of Snap! Websites servers.
Snap! Websites are built to run in a cluster. Because of that, the security of the cluster is mainly insured by the computers in the cluster and not by the servers themselves.
There are a few known points that render the Snap! Websites service weak in terms of security if people other than you can access your computers via a network connection or directly:
The PayPal implementation has been implemented in C++ following the recently developed REST API.
The current implementation supports straight sales and recurring payment plans with setup fees. Recurring payments are limited to ONE recurring product and any number of optional recurring payment setup fee products. All payments are using the PayPal payment method (opposed to PayPal Pro that allows you to directly charge credit card on your website.)
The way the system works with the REST API is different from the SOAP API most of us have been used to. The main significant difference is that ...
When sending the user to your website, it is possible to request the website to add or remove items to the e-Commerce cart. This is done using links build as a set of commands as defined here.
The cart understands the special query string named "cart". The string is built with a set of letters and parameters. The letter 'p' stands for product and it is the activator, meaning that all the parameters prior apply to this 'p', then the parameters get reset. For this reason, you generally want the 'p' command last.
Note that the query string is interpreted ...
Snap! Websites
An Open Source CMS System in C++
