Relying on the the platform to handle the user authentication and document storage is something I wouldn't be comfortable with, though I'd use it as an option (as facebook connect, google or any other authentication service out there).
In general, I think this would have been a hit 5 years ago. Now, with services like heroku, phpfog, app engine, even github having free plans, the "hosting" part seems to be solved, and something pretty similar can be done these days with some sparkle from FB Connect and a bit of rails/php for the client side storage.
Don't get me wrong, I like this kind of services because [I think] they push innovation in different directions. It's just that I think there are a few pretty well stablished and provide similar (or equivalent) functionality and I just don't see any obvious advantage between this service and the others, though I see a few drawbacks.
Good feedback. What I'm aiming for (and trying to see if there are others that this resonates with), is a higher level of abstraction for HTML5-centric application development.
There's a lot to learn to build applications that span database/web server/client - so I'm trying to build a "generic" backend, and let the application developer concentrate on the client side only.
Maybe it's really only applicable to "toy" or "prototype" applications. Like this one, for example:
What Services does Pageforest Provide?
<snip>
Cloud-based Document Storage - Each Pageforest user is given storage for their own document collection in the Cloud. When a user authorizes your application, your App can create and store documents to the user's collection.
Good points. The back end is implemented on App Engine. But we provide an abstracted storage interface. Application can created "documents" (up to 1 MB of JSON, and saved using a HTTP PUT or POST). Our permissions model is based on the document - you can keep a document private to a user, or make it read/write able by others.
In addition, each document can have as many child "blobs" as you want (each blob is up to 1 MB using any format - can be text, png, json, xml, etc.).
Interestingly, each "App" is very similar to a "Document". E.g., you index.html file is a "blob" in the application.
To walk a little further down that path, if there is database access how is validation done since none of the client code can be trusted to have been executed and all input from the client should be considered suspect?
User authentication is handled by the server, and then a session cookie is created on your application sub-domain.
App writers don't have to worry about authentication - just redirect the user to the www.pageforest.com/sign-in/appid page, and the will redirect back to the app if the user has granted the application permissions to save on their behalf (much like a 3-legged oAuth).
Thanks for the answer, but my question isn't about user authentication/validation but validation of input from the user into my application.
A simple example, I set up a survey app. Several of the questions contain user input in the form of dates or numbers such as, date of birth, number of years living in the united states, years employed, etc. To help weed out bogus answers I want the fields to be validated/filtered. Date fields should be dates, numeric fields should only contain digits. In a traditional client server app I can validate this on the client side before submission in javascript, but I would still need to validate it on the server side as the clients input cannot be trusted. There is no guarantee that the validation code was ever run, that the user didn't modify the code as/before it was executed or that the user didn't simply post bogus data via a script.
Much more importantly, if I'm taking user input and then pushing that data back into the page for other users to see how do I prevent someone from submitting malicious javascript that is then executed by the next users browser when they view the document? The pitch is that my application is 100% client side javascript so it would seem to preclude the vast majority of apps that I can even think of since the users input would need to be processed/validated server side before I would be willing to store it or make it available for others to consume.
For your survey app example, why can't you just allow the client to submit bogus data if they want, then filter out the junk when you collect the data for reporting at the end? (This is assuming that the pageforest server doesn't implode when someone does this, but I see no reason to assume this would happen from a theoretical standpoint.)
For you second example, why the heck would you run javascript eval on the document data? As explained by mckoss, the storage format is JSON, not raw javascript that is executed. This is an important distinction: jQuery and other client libraries contain special commands for handling JSON that exist specifically to resolve the kinds of problems you are describing.
EDIT: It looks like the other reply explains that there is no "trusted agent", so this is clearly a limitation of their system (though not a theoretical limitation, as far as I can tell- No reason they couldn't allow the app creator to log in with pseudo-admin privlidges to do reporting.)
Why in the world would I want to collect garbage. Sure I can post process all of the survey data but it's trivial to do it on the front end so why not. In a significant number of other cases failing to validate input would simply be a non starter limiting this to toy apps.
As to the second point: Who said anything about _me_ running a javascript eval on user supplied data.
Go look at their wiki example click edit and in the text box type: <script>alert('boo');</script> then click the hide button.
Notice two things. The first is that when you type the last > on the ending script tag the included script executes and you get the alert popup. When you reload the page you'll still see the alert('boo'); in the wiki display (in <code> tags) but the <script> tag is still live in the page as there's either no or very limited output sanitization. In a typical client/server application this is hopefully going to be sanitized or eliminated prior to ever being stored. The storage format is irrelevant if the data being stored is spit right back out into the page as in the wiki example.
You're absolutely right on the alert issue in the wiki: Displaying unsanitized text in this way is a security bug. However, I think the security bug is in the client app, which should sanitize any data it pulls from the server, if the server data may have originated from another user (if this is even possible in the current pageforest API) not in the inherent design of pageforest.
But that is indeed a good argument in your favor, ktsmith.
Yes - this app is not a good example of doing this "right" (my bad). It should instead sanitize the input before displaying it (especially to another user).
I wasn't trying to pick on your wiki app, it was just a readily available example where input/output sanitization wasn't happening. I'm not sure what your target demographic is, but I would be surprised if this wasn't a very common problem that your potential users encounter. One of the advantages of many of the server side frameworks is that they provide this type of sanitization for free.
Yeah. In this app I used the (very nice) ShownDown.js as a MarkDown format generator. Which DOES properly sanitize most input. I then added the special <script> evaluation stuff as a cool "hack".
As client-side JavaScript gets more mature, I do expect there to be more frameworks that will just "do the right thing" for developers who write code like this.
It is true that you'd need to write your app so that you either segregate user's input (the only one reading a document is the original user who created it), or sanitize user-entered data in the client before displaying it.
I think this is pretty analogous to the traditional client/server model. The only difference is it all happens in the client.
There ARE cases where you need to aggregate data from multiple users, analyze it, and generate a summary, that are not very amenable to the Pageforest model - since there is no "trusted agent" that can execute that code.
Thanks for the quick replies. Given the additional information I can better answer your original question in the post of "would I use this." Due to the lack of a trusted agent anywhere in the stack I don't have any use cases that fit your model and so no I couldn't use it. Maybe a single player game or other toy. For the work that I typically do accessibility is also a huge factor and javascript can only be used for progressive enhancement so I couldn't create a 100% client side javascript application anyway.
BTW, can you explain why you can't do page rendering in JavaScript for accessibility? Is there reason screen readers can deal with dynamically generated HTML?
It's not that page rendering can't be done with JavaScript and still be accessible. My experience with it via testing is that due to the large number of screen readers, and then differences within versions of the even the most common screen readers (JAWS for example) is that you can't really expect a consistent experience for your users where you get much more consistency with vanilla HTML. The single largest complaint we received while testing with screen readers on our latest app was related to how the user was informed by their software about dynamically changed content, something I have no control over. The compromise that we implemented was to try to detect screen readers and offer to disable all JavaScript content since the site was designed to degrade gracefully anyway.
This is going to be less of a problem for some companies than others, I just happen to be working on software that's designed to help HR departments with their hiring process and specifically with the accurate completion of certain federal forms. Getting complaints about violating the ADA could lead to lawsuits against my employer or our clients. Similar to the complaints that Google is receiving about accessibility problems in Google Apps and specifically gmail.
Very interesting. I wonder why Chrome wasn't mentioned at all in the survey.
I would love to find some tools, like a Chrome extension, that could display an accessibility score for a web page and provide guidance on solving problems. For those of us not using screen readers, it's easy to overlook errors without realizing it.
The survey I linked to is the 2009 version there's also a follow up with more info. My guess is that after a year Chromes market share was so small as to be not worth discussing. The newer survey, which I should have linked initially, still doesn't mention but does show improvement over the time span between surveys.
There's a few addons for firefox that focus on section 508 compliance but many of them are poorly maintained. You might want to look into this one, which I have not used myself however.
One other small note. I don't see where document management is handled. I see the document listing and can get back and forth between documents I've created, but I don't see any way to delete those documents.
Possibly using the open source platform, fairly unlikely on a hosted version. Why? I think it's almost certain that at some point I'm going to need some configuration or tweaks to the server side code that are application specific and cannot be done in client side code (validation, heavy lifting or secret sauce things). As nice as it would be to not worry about the service side code, once you get past the basics of a CRUD app, the server side become rather important.
Off the top of my head the biggest early concern I'd have would be how are you going to handle server side validation, since relying solely on client side validation is pretty much just as good an no validation at all. Especially complex validation involving multiple fields. The next would be interacting with things like third party APIs that have access keys that need to be protected or just can't be accessed from the client (because they don't offer a JSONP interface).
Yes, we have our own user validation system (a challenge/response protocol). We actually validate you on the pageforest.com domain, and then transfer a session cookie to your application - so your app never sees the user password/secret.
I would say our sweet spot is smaller, document-centric apps (games, puzzles, document editors). Anything that can use a simple document persistence model.
Google App Engine (and other cloud providers) also places limits on how much you can tweak the server side code. Clearly, there will always be apps that require some crazy server-side C code or whatever, but for 99% of apps all that matters is whether pageforest has exposed enough in the API to take care of the important stuff (validation, etc.)
I'm not saying their API is good enough for this, since they just launched, but from a theoretical standpoint I think the concept is sound.
I just want to say I have been wanting this forever and can't believe no one has provided this before- I'm annoyed you guys beat me to this type of product.
This is exactly how a web app should be created- All the apps I've been creating lately are 95% client-side javascript and 5% of annoying server code that could obviously have been implemented using a generic REST-based data store.
I will be using pageforest extensively (Assuming it's not buggy, etc :-) Hats off to you guys for being first to market on this!
I agree there's definite overlap in their models, from the look of it- But there are still clear differences between these two concepts, with differing strengths and weaknesses.
Thanks for the pointer to unhosted - I've not seen this before. Sounds like a standard protocol to separate application from data storage - pretty similar to the Pageforest model - except federated!
That being said, I agree with andrewjshults that sooner or later you will need to write server side code, even if it is to proxy client side requests to another domain.
mckoss, would it be worth making a server side implementation of your service for http://www.akshell.com - a server side JavaScript platform with syncrhonous I/O and a browser based IDE. We're open sourcing the whole stack, so there would be a lot less lock in than with AppEngine. Drop me a line on our mailing list if you're interested: http://groups.google.com/group/akshell
42 comments
[ 7.4 ms ] story [ 109 ms ] threadRelying on the the platform to handle the user authentication and document storage is something I wouldn't be comfortable with, though I'd use it as an option (as facebook connect, google or any other authentication service out there).
In general, I think this would have been a hit 5 years ago. Now, with services like heroku, phpfog, app engine, even github having free plans, the "hosting" part seems to be solved, and something pretty similar can be done these days with some sparkle from FB Connect and a bit of rails/php for the client side storage.
Don't get me wrong, I like this kind of services because [I think] they push innovation in different directions. It's just that I think there are a few pretty well stablished and provide similar (or equivalent) functionality and I just don't see any obvious advantage between this service and the others, though I see a few drawbacks.
There's a lot to learn to build applications that span database/web server/client - so I'm trying to build a "generic" backend, and let the application developer concentrate on the client side only.
Maybe it's really only applicable to "toy" or "prototype" applications. Like this one, for example:
http://wiki.pageforest.com/
What Services does Pageforest Provide? <snip> Cloud-based Document Storage - Each Pageforest user is given storage for their own document collection in the Cloud. When a user authorizes your application, your App can create and store documents to the user's collection.
They asked for comment and I think they need to be more specific that's all. If they're using the GAE db imho they should say so.
In addition, each document can have as many child "blobs" as you want (each blob is up to 1 MB using any format - can be text, png, json, xml, etc.).
Interestingly, each "App" is very similar to a "Document". E.g., you index.html file is a "blob" in the application.
App writers don't have to worry about authentication - just redirect the user to the www.pageforest.com/sign-in/appid page, and the will redirect back to the app if the user has granted the application permissions to save on their behalf (much like a 3-legged oAuth).
A simple example, I set up a survey app. Several of the questions contain user input in the form of dates or numbers such as, date of birth, number of years living in the united states, years employed, etc. To help weed out bogus answers I want the fields to be validated/filtered. Date fields should be dates, numeric fields should only contain digits. In a traditional client server app I can validate this on the client side before submission in javascript, but I would still need to validate it on the server side as the clients input cannot be trusted. There is no guarantee that the validation code was ever run, that the user didn't modify the code as/before it was executed or that the user didn't simply post bogus data via a script.
Much more importantly, if I'm taking user input and then pushing that data back into the page for other users to see how do I prevent someone from submitting malicious javascript that is then executed by the next users browser when they view the document? The pitch is that my application is 100% client side javascript so it would seem to preclude the vast majority of apps that I can even think of since the users input would need to be processed/validated server side before I would be willing to store it or make it available for others to consume.
For you second example, why the heck would you run javascript eval on the document data? As explained by mckoss, the storage format is JSON, not raw javascript that is executed. This is an important distinction: jQuery and other client libraries contain special commands for handling JSON that exist specifically to resolve the kinds of problems you are describing.
EDIT: It looks like the other reply explains that there is no "trusted agent", so this is clearly a limitation of their system (though not a theoretical limitation, as far as I can tell- No reason they couldn't allow the app creator to log in with pseudo-admin privlidges to do reporting.)
As to the second point: Who said anything about _me_ running a javascript eval on user supplied data.
Go look at their wiki example click edit and in the text box type: <script>alert('boo');</script> then click the hide button.
Notice two things. The first is that when you type the last > on the ending script tag the included script executes and you get the alert popup. When you reload the page you'll still see the alert('boo'); in the wiki display (in <code> tags) but the <script> tag is still live in the page as there's either no or very limited output sanitization. In a typical client/server application this is hopefully going to be sanitized or eliminated prior to ever being stored. The storage format is irrelevant if the data being stored is spit right back out into the page as in the wiki example.
But that is indeed a good argument in your favor, ktsmith.
As client-side JavaScript gets more mature, I do expect there to be more frameworks that will just "do the right thing" for developers who write code like this.
BTW, can you explain why you can't do page rendering in JavaScript for accessibility? Is there reason screen readers can deal with dynamically generated HTML?
This is going to be less of a problem for some companies than others, I just happen to be working on software that's designed to help HR departments with their hiring process and specifically with the accurate completion of certain federal forms. Getting complaints about violating the ADA could lead to lawsuits against my employer or our clients. Similar to the complaints that Google is receiving about accessibility problems in Google Apps and specifically gmail.
Here's a pretty good survey that has some more information if you are interested in the topic: http://webaim.org/projects/screenreadersurvey2/
I would love to find some tools, like a Chrome extension, that could display an accessibility score for a web page and provide guidance on solving problems. For those of us not using screen readers, it's easy to overlook errors without realizing it.
http://webaim.org/projects/screenreadersurvey3/
There's a few addons for firefox that focus on section 508 compliance but many of them are poorly maintained. You might want to look into this one, which I have not used myself however.
https://addons.mozilla.org/en-us/firefox/addon/qompliance/
http://wiki.pageforest.com/#pageforest-api/storage
Simpler apps will save their state in a document created for the user (up to 1 MB). But you can do more using the "Blob" storage interface.
Off the top of my head the biggest early concern I'd have would be how are you going to handle server side validation, since relying solely on client side validation is pretty much just as good an no validation at all. Especially complex validation involving multiple fields. The next would be interacting with things like third party APIs that have access keys that need to be protected or just can't be accessed from the client (because they don't offer a JSONP interface).
I would say our sweet spot is smaller, document-centric apps (games, puzzles, document editors). Anything that can use a simple document persistence model.
I'm not saying their API is good enough for this, since they just launched, but from a theoretical standpoint I think the concept is sound.
This is exactly how a web app should be created- All the apps I've been creating lately are 95% client-side javascript and 5% of annoying server code that could obviously have been implemented using a generic REST-based data store.
I will be using pageforest extensively (Assuming it's not buggy, etc :-) Hats off to you guys for being first to market on this!
Seriously, thanks for giving it a try - I'd love to get your feedback on problems you have using the platform...
Friday night networking! :-)
That being said, I agree with andrewjshults that sooner or later you will need to write server side code, even if it is to proxy client side requests to another domain.
mckoss, would it be worth making a server side implementation of your service for http://www.akshell.com - a server side JavaScript platform with syncrhonous I/O and a browser based IDE. We're open sourcing the whole stack, so there would be a lot less lock in than with AppEngine. Drop me a line on our mailing list if you're interested: http://groups.google.com/group/akshell