4 ms·

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 authen

by mckoss 16y ago

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).

deleted 16y ago
[deleted]
ktsmith 16y ago
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.
- drcode 16y ago
  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.)
  - ktsmith 16y ago
    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.
    - drcode 16y ago
      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.
    - mckoss 16y ago
      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).
      - ktsmith 16y ago
        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.
- mckoss 16y ago
  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.
  - ktsmith 16y ago
    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.
    - mckoss 16y ago
      Thanks so much for the thoughtful feedback. 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?
      - ktsmith 16y ago
        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. Here's a pretty good survey that has some more information if you are interested in the topic: http://webaim.org/projects/screenreadersurvey2/ http://webaim.org/projects/screenreadersurvey2/

by mckoss 16y ago

deleted 16y ago

[deleted]

ktsmith 16y ago

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.

drcode 16y ago
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.)
- ktsmith 16y ago
  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.
  - drcode 16y ago
    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.
  - mckoss 16y ago
    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).
    - ktsmith 16y ago
      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.
mckoss 16y ago
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.
- ktsmith 16y ago
  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.
  - mckoss 16y ago
    Thanks so much for the thoughtful feedback. 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?
    - ktsmith 16y ago
      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. Here's a pretty good survey that has some more information if you are interested in the topic: http://webaim.org/projects/screenreadersurvey2/ http://webaim.org/projects/screenreadersurvey2/