Sunday, December 9, 2012
Boilerplate
Rdbhost is a tool for getting simple web apps going quickly.
In support of that position, we now have boilerplate bundles; these are downloadable zip files that can be unzipped to your harddrive, and immediately function as simple applications. Your account information is already embedded in each, so it will just run, and access your Rdbhost account as necessary.
The wizard collects from you the necessary information to create the boilerplate bundle. After the wizard completes, you can download the relevant bundles from the boilerplate page; each includes a README.txt with starter instructions.
For now, there are as many as three boilerplate bundles, depending on your wizard selections; one for the Python Rdbhdb module, one for Python's SQLObject, and one for a JavaScript web app. There will be more, in time, including options for html boilerplate, and these (especially the JavaScript bundle) will be enhanced.
Try them out, let me know if they don't behave as expected.
David Keeney
dkeeney@rdbhost.com
Friday, June 8, 2012
running Credit Card Charges for Rdbhost Applications.
More and more types of services that once were exclusively 'server-side' on your web-server, are now independently hosted web services, accessible via a web API.
One such task is handling credit card charges; Stripe.com handles credit card processing through a web API. Rdbhost now supports handling charges for your hosted web application via Stripe.com. This is the second web-service we support, after email.
This service works similarly to the email mode, in that a query pulls the input data for the charge, including CC Num, CCV, expiration, etc, formulates a Stripe request from it, submits it, retrieves the result from Stripe, calls a database function to store the result, and then returns a summary status record to the client, via the selected data format. Any or all of the results of the initial query can be concealed from the client, for customer privacy and security reasons.
CC Charging uses a new mode, called 'charge'. Each record returned by the submitted query must contain a certain set of fields, to include 'ccnum', 'amt', 'apikey', 'service' and 'currency'. One charge is run for each such record.
Since the actual charging is done by a third party email web-service, you need to set up an account on stripe.com; they will provide you the API key.
The result page is formatted just as the result page for email mode, with either 'success' or an error message for each record processed.
jQuery Rdbhost Plugin
The jQuery plugin does not have any specific methods for charging, but the $.postData method will suffice, and the example linked below shows how to use it that way. This example only relies on database storage for the api key, as that needs protecting from the end user.
Example Payment Page
Rdbhost Documentation on Charge Feature
Saturday, June 2, 2012
and Now Email, too
Toward our goal of making Rdbhost.com a universal backend, suitable for supporting a wide range of websites with no custom server-side coding, we have taken a large step in adding emailing capability.
Now, clients can send email through a query request, without Rdbhost disclosing to the client who the recipients are. This can be useful in implementing password recovery systems and initial password emails, for example.
The implementation is in the form of a new mode, called 'email'. The Rdbhost request protocol has a new parameter called 'mode'. The default mode is to just send the query results to the client. For other modes, there will be some intermediate step that takes the query results, does something, and returns another set of results. The first such mode to be implemented is email. The query results are input to the emailer, and the success/failure status of each email attempt is returned as the result to the client.
Each record returned by the submitted query must contain a certain set of fields, to include 'To:', 'From:', 'apikey', 'service' and 'body'. One email is sent for each such record.
The actual emailing is done by a third party email webservice of your choice. So far, we support postmarkapp.com and emailyak.com. The 'service' field indicates which service you are using, and 'apikey' must contain the corresponding API key. Before using email on Rdbhost, you must set up an account on one of those services; they will provide you the API key.
A very simple 'proof of function' email query might look like:
The preceding example revealed the API key as well as the to: address. If you were to use this query verbatim, you would want to use keyword lookup and restrict it to white-listed roles (Preauth or Auth), to prevent the API Key from being disclosed. You would also need to deny SELECT priv to the reader role to the lookup table, to keep the query from being read.
This is a bit of trouble, and constrains other uses of the lookup table. It would be easier to just move the private elements out of the query statement into tables, and restrict access to those tables.
A more typical query might look like:
After the emailng is complete, a page body is sent to the client indicating the apparent success or failure of the emailing. The page is in json or xml format, and conveys a list of email send events, each entry including a unique key and 'Success' or an error code as returned by their API. The preferred page format is specified as the format parameter..
The resulting page, in json, would resemble:
Be aware that this only reports immediate errors from the API. If the recipient address is bad, that will not be known until later, and you would need to use the email service's own reporting pages to evaluate that.
jQuery Rdbhost Plugin
The jQuery plugin does not have any specific methods for emailing, but the $.postData method will suffice, and the example linked below shows how to use it that way. This example only relies on database storage for the api key, as that needs protecting from the end user. Your applications may well retrieve From or To addresses from a database as well. The example application cannot be used to send spam to arbitrary addresses, as the recipient is hard-coded into the query, and the query itself is white-listed (variants will not pass the white-list).
Example Emailing Page
Rdbhost Documentation on Emailing Feature
Now, clients can send email through a query request, without Rdbhost disclosing to the client who the recipients are. This can be useful in implementing password recovery systems and initial password emails, for example.
The implementation is in the form of a new mode, called 'email'. The Rdbhost request protocol has a new parameter called 'mode'. The default mode is to just send the query results to the client. For other modes, there will be some intermediate step that takes the query results, does something, and returns another set of results. The first such mode to be implemented is email. The query results are input to the emailer, and the success/failure status of each email attempt is returned as the result to the client.
Each record returned by the submitted query must contain a certain set of fields, to include 'To:', 'From:', 'apikey', 'service' and 'body'. One email is sent for each such record.
The actual emailing is done by a third party email webservice of your choice. So far, we support postmarkapp.com and emailyak.com. The 'service' field indicates which service you are using, and 'apikey' must contain the corresponding API key. Before using email on Rdbhost, you must set up an account on one of those services; they will provide you the API key.
A very simple 'proof of function' email query might look like:
SELECT 'me@example.com' AS "From:",
'you@example2.com' AS "To:",
'abcd12345xyz' AS "apikey",
'yak' AS "service",
'test message' AS "Subject:",
1 AS "Idx",
'Test from Rdbhost.\nHey there' AS "body";
This will send one email to 'you@example2.com'.The preceding example revealed the API key as well as the to: address. If you were to use this query verbatim, you would want to use keyword lookup and restrict it to white-listed roles (Preauth or Auth), to prevent the API Key from being disclosed. You would also need to deny SELECT priv to the reader role to the lookup table, to keep the query from being read.
This is a bit of trouble, and constrains other uses of the lookup table. It would be easier to just move the private elements out of the query statement into tables, and restrict access to those tables.
A more typical query might look like:
SELECT cust.email AS "To:",
'me@example.com' AS "From:",
'news this week' AS "Subject:",
api.apikey AS "apikey",
'yak' AS "service",
tpl.body AS "body",
cust.id AS "Idx"
FROM customers AS cust,
email_service_info AS api,
email_templates AS tpl
WHERE email_templates.type = 'weeklynews';
This would send the contents of email_templates.body to each customer in the customers table.After the emailng is complete, a page body is sent to the client indicating the apparent success or failure of the emailing. The page is in json or xml format, and conveys a list of email send events, each entry including a unique key and 'Success' or an error code as returned by their API. The preferred page format is specified as the format parameter..
The resulting page, in json, would resemble:
{ "records": { "header": [ [ 23, "idx" ], [ 705, "result" ] ], "rows": [ [ 2, "Success" ] ] }, "row_count": [ 1, "1 Rows Affected" ], "status": [ "complete", "OK" ] }
Be aware that this only reports immediate errors from the API. If the recipient address is bad, that will not be known until later, and you would need to use the email service's own reporting pages to evaluate that.
jQuery Rdbhost Plugin
The jQuery plugin does not have any specific methods for emailing, but the $.postData method will suffice, and the example linked below shows how to use it that way. This example only relies on database storage for the api key, as that needs protecting from the end user. Your applications may well retrieve From or To addresses from a database as well. The example application cannot be used to send spam to arbitrary addresses, as the recipient is hard-coded into the query, and the query itself is white-listed (variants will not pass the white-list).
Example Emailing Page
Rdbhost Documentation on Emailing Feature
Monday, May 28, 2012
OpenID logins
Third party user authentication is popular these days. This allows you to use one login id with multiple websites.
You may want to use OpenId with your Rdbhost backed website, to give your users the convenience of using their single-login. OpenId is one of the two widely used third pary authentication protocols.
We have added OpenId verification to our API. You can invite your users to login using OpenId, present that login request to the Rdbhost server using the JavaScript API, and the server will handle the verification process and return the outcome to you, along with a session key (if authenticated) for that user to access your database services. Note that this session key is just a key for use in authenticating a user, or authorizing database access; coding the key-based constraints is an app design issue.
Third party login is quite appealing to users, and seems to be becoming an expected feature of new web apps. We are happy to support this for your Rdbhost hosted apps.
OpenID login is enabled from your profile page on the Rdbhost website. When the feature is enabled, a new schema 'auth' is created, a simple user tracking table is created there, and a PL/pgSQL database procedure is created for you to handle OpenID logins. You can override this procedure with your own, to implement custom login handling.
An example is at:
http://www.paginaswww.com/rdb/examples/openid-login.html
and details are at:
http://www.rdbhost.com/openid_login.html
The jQuery plugin has been updated as well, to support OpenID logins:
http://github.com/rdbhost/Rdb.js
Monday, April 23, 2012
Javascript API made easier; no domain management required
The javascript API library for Rdbhost has been updated, and is now even easier to use to access Rdbhost hosted databases from your javascript application. No longer do you need to to set up a domain pointer from a subdomain of your site domain to the rdbhost server.
Just include the new jquery.rdbhost.exdm.js module in your page, pass your account role and authcode to the $.rdbhostConfig call, and use the provided methods to access your Rdbhost database; the library includes both an SQLEngine class with query methods, and also a jQuery plugin that applies query results to selected element sets.
The jquery.rdbhost.exdm.js module is based on Oyvind Kinsey's easy-xdm library, which uses a variety of inter-domain messaging techniques to enable returning data from the Rdbhost server to your page on any domain. We do apply CORS domain-checking to prevent unauthorized cross-domain access, but the default CORS authorization provided for new accounts is the wildcard '*' permitting all domains, including localhost. When you finish the app and move it to a public server, specify the domain as a remote host in Rdbhost website management page.
The module is at: https://github.com/rdbhost/Rdb.Js
There are example pages for various API methods at: http://www.paginaswww.com/rdb/examples
The jQuery plugin has been extended to support OpenID logins, as well:
http://github.com/rdbhost/Rdb.js
Just include the new jquery.rdbhost.exdm.js module in your page, pass your account role and authcode to the $.rdbhostConfig call, and use the provided methods to access your Rdbhost database; the library includes both an SQLEngine class with query methods, and also a jQuery plugin that applies query results to selected element sets.
The jquery.rdbhost.exdm.js module is based on Oyvind Kinsey's easy-xdm library, which uses a variety of inter-domain messaging techniques to enable returning data from the Rdbhost server to your page on any domain. We do apply CORS domain-checking to prevent unauthorized cross-domain access, but the default CORS authorization provided for new accounts is the wildcard '*' permitting all domains, including localhost. When you finish the app and move it to a public server, specify the domain as a remote host in Rdbhost website management page.
The module is at: https://github.com/rdbhost/Rdb.Js
There are example pages for various API methods at: http://www.paginaswww.com/rdb/examples
The jQuery plugin has been extended to support OpenID logins, as well:
http://github.com/rdbhost/Rdb.js
Friday, July 15, 2011
Named Query Parameters
The Rdbhost protocol now uses named parameters in addition to positional parameters.
Where before you could submit a query like:
Now you can make it more readable, like:
This addition has a couple of benefits. The first is the greater readability and greater ease in assuring the correct parameter values are matched to the correct query tokens.
The other is that each parameter can be used in the query multiple times. For example, in the following snippet, we want to ensure that the value is at least 0.
The query snippet could be written with positional parameters, but there would then be no way to ensure the same value is passed as both values, and a negative value could be returned. Using a named parameter ensures that parameter value is used both times.
Where before you could submit a query like:
<input name="q"
value="SELECT * FROM personnel WHERE firstName = %s AND lastName = %s" />
<input name="arg000" value="John" />
<input name="arg001" value="Smith" />
Now you can make it more readable, like:
<input name="q" value="SELECT * FROM personnel WHERE firstName = %(first) AND lastName = %(last)" />
<input name="arg:first" value="John" />
<input name="arg:last" value="Smith" />
This addition has a couple of benefits. The first is the greater readability and greater ease in assuring the correct parameter values are matched to the correct query tokens.
The other is that each parameter can be used in the query multiple times. For example, in the following snippet, we want to ensure that the value is at least 0.
CASE WHEN (%(val))<=0 THEN trunc(%(val),6) ELSE 0.00 END
The query snippet could be written with positional parameters, but there would then be no way to ensure the same value is passed as both values, and a negative value could be returned. Using a named parameter ensures that parameter value is used both times.
Saturday, July 2, 2011
Using your own SSL/TLS Certificate
Rdbhost now supports your using your own SSL/TLS certificate for your rdbhost subdomain, to encrypt and authenticate data transfer with your account at www.rdbhost.com.
The SSL/TLS certificates have two purposes, encryption and authentication. Any certificate, including a free self-signed certificate, will enable the server to encrypt data transferred between server and client. This encryption prevents data from being observed by eavesdroppers who might have access to your data stream.
However, a connection encrypted with a non-authenticated certificate is vulnerable to a type of attack known as a 'man in the middle' attack. If someone can insert a proxy into the network path between the client and the server, they can conduct a 'man in the middle' attack, impersonating each end of the connection to the other end. When the client (browser) requests a certificate, the proxy sends its own, and then requests a cert from the server. The proxy would hold a certificate for each half of the connection, and thus decrypt and encrypt all data passing through, recording whatever part it is interested in intercepting. This attack can happen because with an un-authenticated certificate, the client has no way of knowing that it is getting a cert from the proxy rather than the server.
The way to prevent this sort of 'man in the middle' attack, if it concerns you, is to use an authenticated, or 'trusted', certificate. If you purchase a 'trusted' certificate from vendor, they supposedly verify that you are indeed the owner of the site, and issue you a certificate that is digitally signed by them using their own trusted certificate. The client can verify the issuers signature with the issuer directly, and thus be assured that the certificate you present is your own. The 'man in the middle' attacker can present a certificate, but presumably would not be able to convince a trusted certificate issuer that they owned *your* domain, and thus could not present a certificate for your domain with a trusted issuer certificate.
There are a few certificate issuers that are trusted by all browsers as released. If your vendor is not one of those, they will have a certificate signed by one of those, sign your certificate with theirs, and send a bundle of certificates that establish a chain of trust from a trusted issuer to you. Godaddy.com is a very popular issuer of certificates, and they issue a bundle file with multiple certificates to establish the chain of trust. The client browser can see who signed your certificate, read the issuers certificate and find who signed it, and repeat until an intrinsically trusted issuer is found.
Even if you are not very worried about someone conducting such an attack, you might still want a signed certificate to avoid browser warnings. Browsers, especially Firefox, can be very assertive about warning users of perceived limitations in a site's certificate. Having a trusted certificate avoids warnings and gives the user a smoother user experience. The warnings are so common these days, that many users are blase about it, but it is your call as to how tolerant your users will be.
Buy your trusted certificate from a vendor of your choice. There are websites that will create a public key pair and a CSR Certificate Signing Request for you, and you should create the CSR using your domain and the subdomain you use for Rdbhost server access, for example rdbhost.mydomain.com. The certificate vendor will create a certificate based on the CSR and make it available for download.
If you have not registered a domain alias on the site, do so now, registering the domain and subdomain, that you use for Rdbhost database access, for example 'rdbhost.mydomain.com'. The domain alias page is linked from the profile page.
If you have not entered the subdomain into the DNS zone manager of your domain registrar, you need to do so.
Visit the Certificate Manager on www.rdbhost.com and paste the certificate into the form field. If your vendor provides a chain (or 'bundle') file, paste it in after your certificate. Paste the private key in at the beginning or the end. Each of these files is a simple text file, so it can be opened in a text editor for cutting and pasting.
Within a minute or two after submitting the form, your account will be accessible using that domain, secured by SSL/TLS and your authenticated certificate.
This SSL/TLS service relies on SNI Server Name Indication, an extension to the HTTP protocol. SNI is supported by many modern browsers, but not all. On Windows, notably, SNI handling is left to the OS by most browser brands, and while Vista and later support it, XP does not.
If your user is accessing the database using a browser that does not support SNI, they will get the default Rdbhost certificate, in lieu of your trusted certificate.
As always, comments are welcome.
Why Use Certificates
The SSL/TLS certificates have two purposes, encryption and authentication. Any certificate, including a free self-signed certificate, will enable the server to encrypt data transferred between server and client. This encryption prevents data from being observed by eavesdroppers who might have access to your data stream.
However, a connection encrypted with a non-authenticated certificate is vulnerable to a type of attack known as a 'man in the middle' attack. If someone can insert a proxy into the network path between the client and the server, they can conduct a 'man in the middle' attack, impersonating each end of the connection to the other end. When the client (browser) requests a certificate, the proxy sends its own, and then requests a cert from the server. The proxy would hold a certificate for each half of the connection, and thus decrypt and encrypt all data passing through, recording whatever part it is interested in intercepting. This attack can happen because with an un-authenticated certificate, the client has no way of knowing that it is getting a cert from the proxy rather than the server.
The way to prevent this sort of 'man in the middle' attack, if it concerns you, is to use an authenticated, or 'trusted', certificate. If you purchase a 'trusted' certificate from vendor, they supposedly verify that you are indeed the owner of the site, and issue you a certificate that is digitally signed by them using their own trusted certificate. The client can verify the issuers signature with the issuer directly, and thus be assured that the certificate you present is your own. The 'man in the middle' attacker can present a certificate, but presumably would not be able to convince a trusted certificate issuer that they owned *your* domain, and thus could not present a certificate for your domain with a trusted issuer certificate.
There are a few certificate issuers that are trusted by all browsers as released. If your vendor is not one of those, they will have a certificate signed by one of those, sign your certificate with theirs, and send a bundle of certificates that establish a chain of trust from a trusted issuer to you. Godaddy.com is a very popular issuer of certificates, and they issue a bundle file with multiple certificates to establish the chain of trust. The client browser can see who signed your certificate, read the issuers certificate and find who signed it, and repeat until an intrinsically trusted issuer is found.
User Experience
Even if you are not very worried about someone conducting such an attack, you might still want a signed certificate to avoid browser warnings. Browsers, especially Firefox, can be very assertive about warning users of perceived limitations in a site's certificate. Having a trusted certificate avoids warnings and gives the user a smoother user experience. The warnings are so common these days, that many users are blase about it, but it is your call as to how tolerant your users will be.
The Rdbhost Way
Buy your trusted certificate from a vendor of your choice. There are websites that will create a public key pair and a CSR Certificate Signing Request for you, and you should create the CSR using your domain and the subdomain you use for Rdbhost server access, for example rdbhost.mydomain.com. The certificate vendor will create a certificate based on the CSR and make it available for download.
If you have not registered a domain alias on the site, do so now, registering the domain and subdomain, that you use for Rdbhost database access, for example 'rdbhost.mydomain.com'. The domain alias page is linked from the profile page.
If you have not entered the subdomain into the DNS zone manager of your domain registrar, you need to do so.
Visit the Certificate Manager on www.rdbhost.com and paste the certificate into the form field. If your vendor provides a chain (or 'bundle') file, paste it in after your certificate. Paste the private key in at the beginning or the end. Each of these files is a simple text file, so it can be opened in a text editor for cutting and pasting.
Within a minute or two after submitting the form, your account will be accessible using that domain, secured by SSL/TLS and your authenticated certificate.
Limitations
This SSL/TLS service relies on SNI Server Name Indication, an extension to the HTTP protocol. SNI is supported by many modern browsers, but not all. On Windows, notably, SNI handling is left to the OS by most browser brands, and while Vista and later support it, XP does not.
If your user is accessing the database using a browser that does not support SNI, they will get the default Rdbhost certificate, in lieu of your trusted certificate.
As always, comments are welcome.
Subscribe to:
Posts (Atom)
Posts
