171–180 of 186 posts
Earlier quoted context omitted.
I took that to mean use both identity management as well as OAuth.
1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers? 2. Security best practices subject to "open for interpretation."
Can you explain me this? How Google will be able to access my service data?
Rails has most of this out of the box. Use Rails :)
If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…
If you can afford it, buy a proven security solution. For example use an IBM Datapower or ISAM appliance (or similar from F5). Enterprises will choose something like this to secure their many internal web applications.
The end result of better code is far better than a magical appliance.
> Confirm emails Why?
>If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. Has anyone built a lasting stand-alone business that relies on Facebook, et al for identity management?
http://www.businessinsider.com/jmp-securities-analyst-note-o...
Earlier quoted context omitted.
> What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. I was refering specifically to websites, not webapps. > It's really not the end of story, and i…
Thank you for making these points, I'm just disappointed at how often they need repeating for some people, do you know of a website that explains the reasoning behind not relying 100% on JavaScript for your website? There's motherfuckingwebsite.com but the tone of that site is very adversarial, I think one that lays out the reasoning in a noncombative way would be more successful at reaching some of these people.
There's also this post, that goes into it somewhat: http://allinthehead.com/retro/367/why-is-progressive-enhance... - also, Brad Frost has some posts about this.
Earlier quoted context omitted.
> JavaScript is an integral part of the platform that is the web, just like HTML and CSS I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument. By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea…
> By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea what the UA's capabilities are, up to and including whether or not it's doing any kind of visual rendering at all. I think that is just an outdated idea that does not apply to highly interactive, long-lived web applicatio…
A forum, for example, isn't highly interactive, whereas an online spreadsheet editor is.
Earlier quoted context omitted.
> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. H…
Come on, really? Some of those are legit (although manageable if you do things right), but how many web Apps truly need to worry about accommodating terminal based browser users ? Unless Stallman is in your target market that's probably something you don't need to consider for any longer than fifteen seconds.
Earlier quoted context omitted.
> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the In…
I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.
Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.