5 ms·

(I work on HiFi) You're 100% right. What we're describing sounds a lot like waterfall. Here are a couple more details: * Our team of devs have collectively b

(I work on HiFi) You're 100% right. What we're describing sounds a lot like waterfall. Here are a couple more details: * Our team of devs have collectively built over 450 websites. We know the domain well. * We also did a lot of UI design early on that guided some some of our work. That said, we didn't just design and give birth to a great API. We have iterated on a it a lot. Our clients were going on HiFi 6 months prior to the public release. We learned a lot and iterated on the API quite a bit during that period. What ended up being nice was the ability to make sweeping changes at one point (the API) that benefited the entire application. This is a huge advantage.

StavrosK 16y ago
Can you post a few more details, such as how you handled authentication, how views pass the session to the server (or do you use cookies for all that?), how the calls are being made (does each page do XHR calls and then render the results using logic itself?), etc?
- JoelSutherland 16y ago
  I'm not the right person to answer all of these (the post author is). I'll do my best on what I can. For permissions, there are five levels of users. System, Agency, Site Owner, Member, Public. These are hierarchical like everything else. Group members and individual users can have varying read/write/create permissions for different areas of the content tree. This is all at the API level. So someone logged in will have the same permissions whether they are browsing the frontend of the site, the administration UI or using the API. This is nice, tidy and easy to understand. As for XHR vs not... In the Admin UI, we're doing most work through the API via XHR and JS templates. On the public site of things, everything happens server side just like any other CMS.
  - StavrosK 16y ago
    Thanks, I'm just wondering because, even though this approach had fantastic advantages, there also seem to be some things which are done differently in an API. For example, the API might use OAuth after logging the user in with credentials, so this is a case where things are done differently in the two approaches. In this case, does one simply write two ways of doing things? You might also not want to let the users do things with the api that they can do on the site, or give different permissions to the site versus the API. How do you handle these things?
- KrisJordan 16y ago
  Re: authentication. There are three paths to authentication presently. 1) Anonymous - Anonymous is a subject in the system with explicit permissions. When no authentication is presented the system assumes you are the anonymous subject. This is the common case because most website content, for the types of websites we've seen on HiFi, are made up of entirely publicly readable content. 2) Cookie Based - We use your typical web app SHA1 hash with generated salt. Not the greatest form of authentication, susceptible to replay, but preferable to HTTP Basic. 3) HTTP Basic Based - Want to get rid of this sooner than later. Need to invest in digest but it has its problems. This is not used in the app but is useful for server-server API consumption, cURL scripts, etc. As Joel mentioned, the backend is largely XHR driven. Results are rendered primarily with an evolution of Resig's JS templates (http://ejohn.org/blog/javascript-micro-templating/ http://ejohn.org/blog/javascript-micro-templating/). When time permits we'll move to the now official jQuery templates (http://api.jquery.com/jquery.tmpl/ http://api.jquery.com/jquery.tmpl/). Most website frontends consume the API directly in template while still server-side. Some go further and leverage the API from JS/XHR to make pages more interactive.
  - StavrosK 16y ago
    I see, thank you very much for the explanation.
  - getsat 16y ago
    > We use your typical web app SHA1 hash with generated salt. Oh, no! casts summon tptacek Actually, in his absence, I'll link to this recent topic on HN: http://news.ycombinator.com/item?id=2004833 http://news.ycombinator.com/item?id=2004833 This is particularly relevant given the recent complete and utter ownage of Gawker and friends. Had they been using SHA1 (whether or not they had a fancy, home-grown salting/obscurity system to use with it) instead of DES, the result would have been basically the same. tl; dr: SHA1 is FAST. Do NOT use it. Use bcrypt. Please.
    - JoelSutherland 16y ago
      Kris is talking about authentication, not password storage.

StavrosK 16y ago

Can you post a few more details, such as how you handled authentication, how views pass the session to the server (or do you use cookies for all that?), how the calls are being made (does each page do XHR calls and then render the results using logic itself?), etc?

JoelSutherland 16y ago
I'm not the right person to answer all of these (the post author is). I'll do my best on what I can. For permissions, there are five levels of users. System, Agency, Site Owner, Member, Public. These are hierarchical like everything else. Group members and individual users can have varying read/write/create permissions for different areas of the content tree. This is all at the API level. So someone logged in will have the same permissions whether they are browsing the frontend of the site, the administration UI or using the API. This is nice, tidy and easy to understand. As for XHR vs not... In the Admin UI, we're doing most work through the API via XHR and JS templates. On the public site of things, everything happens server side just like any other CMS.
- StavrosK 16y ago
  Thanks, I'm just wondering because, even though this approach had fantastic advantages, there also seem to be some things which are done differently in an API. For example, the API might use OAuth after logging the user in with credentials, so this is a case where things are done differently in the two approaches. In this case, does one simply write two ways of doing things? You might also not want to let the users do things with the api that they can do on the site, or give different permissions to the site versus the API. How do you handle these things?
KrisJordan 16y ago
Re: authentication. There are three paths to authentication presently. 1) Anonymous - Anonymous is a subject in the system with explicit permissions. When no authentication is presented the system assumes you are the anonymous subject. This is the common case because most website content, for the types of websites we've seen on HiFi, are made up of entirely publicly readable content. 2) Cookie Based - We use your typical web app SHA1 hash with generated salt. Not the greatest form of authentication, susceptible to replay, but preferable to HTTP Basic. 3) HTTP Basic Based - Want to get rid of this sooner than later. Need to invest in digest but it has its problems. This is not used in the app but is useful for server-server API consumption, cURL scripts, etc. As Joel mentioned, the backend is largely XHR driven. Results are rendered primarily with an evolution of Resig's JS templates (http://ejohn.org/blog/javascript-micro-templating/ http://ejohn.org/blog/javascript-micro-templating/). When time permits we'll move to the now official jQuery templates (http://api.jquery.com/jquery.tmpl/ http://api.jquery.com/jquery.tmpl/). Most website frontends consume the API directly in template while still server-side. Some go further and leverage the API from JS/XHR to make pages more interactive.
- StavrosK 16y ago
  I see, thank you very much for the explanation.
- getsat 16y ago
  > We use your typical web app SHA1 hash with generated salt. Oh, no! casts summon tptacek Actually, in his absence, I'll link to this recent topic on HN: http://news.ycombinator.com/item?id=2004833 http://news.ycombinator.com/item?id=2004833 This is particularly relevant given the recent complete and utter ownage of Gawker and friends. Had they been using SHA1 (whether or not they had a fancy, home-grown salting/obscurity system to use with it) instead of DES, the result would have been basically the same. tl; dr: SHA1 is FAST. Do NOT use it. Use bcrypt. Please.
  - JoelSutherland 16y ago
    Kris is talking about authentication, not password storage.