Am I like the only person who thinks that the world's mad rush to move all business logic into the client, in the form of Angular/React/whatever the latest thing is, is basically developers scrambling for the biggest bazooka possible with which to blow off their own feet? JavaScript is by its nature unencrypted and unauthenticated and transparent to the end user. Anyone who can load the webapp basically gets a free copy of the entire application. It's one thing if the (protected, authenticated, opaque) API that feeds it represents a complex pile of unique business logic in itself, like if it's a dispatching system or it's doing some clever proprietary processing before returning results. But if your back-end is just a REST-ish representation of a database, like if it's a fairly simple schema of objects in basic relationships, reverse-engineering it is comparatively trivial. Showing someone your front-end is basically saying "Please steal my webapp, all you've got to do is mock up some storage models and you're good to go". If your business' secret sauce is all in the back-end and the client side is just a pretty face for it, well, great, I guess. But if the entire development effort is focused on the front-end, as so many seem to be these days, isn't it just training devs to be comfortable basically walking down the street with business-critical assets dangling out of their pockets?
|
|
# ? Jul 6, 2016 17:32 |
|
|
# ? Jun 5, 2024 09:28 |
|
Data Graham posted:Am I like the only person who thinks that the world's mad rush to move all business logic into the client, in the form of Angular/React/whatever the latest thing is, is basically developers scrambling for the biggest bazooka possible with which to blow off their own feet? All the important stuff should really be taking place on the server anyways. SPAs don't fundamentally change that, they really just move the DOM manipulation part to the client. Your backend (should) still be doing all the parts that matter.
|
# ? Jul 6, 2016 17:45 |
|
Data Graham posted:Am I like the only person who thinks that the world's mad rush to move all business logic into the client, in the form of Angular/React/whatever the latest thing is, is basically developers scrambling for the biggest bazooka possible with which to blow off their own feet? I think it's more to do with "Hey, we have an iOS app, an Android app, some partner integrations, and they all access data via API, so why are we writing all this [ Django / Rails / Laravel / whatever ] code for our web app that accesses data in it's own special snowflake way?" So sure, you can have the web server make API requests and then render views to send down, but why not save all the processing of rendering views* and have JS on the client do it? I can't think of any "Business logic" that would *ever* go on in my React SPAs. Not because I don't want anyone stealing it, but because trusting the client is stupid. The API has all my business logic in it. Sure I might mimic some light version of it for client-side validation, but the meat is all on the back-end. If your back-end really is a straight up REST-ish view of the DB, then you probably don't have much worth stealing =) * minus the first one if you are doing server-side rendering, which you should be.
|
# ? Jul 6, 2016 17:47 |
I mean that's how I'm going to keep doing things, but it sure seems like a lot of teams aren't getting the memo. A lot of new devs are going to get a hard lesson sooner or later.Lumpy posted:* minus the first one if you are doing server-side rendering, which you should be. I get absolutely no takers when I suggest server-side rendering anymore, or even jQuery. "Oh that's so old " loving table views with infinite scrolling fed by APIs and driven by web workers — just because a 20-year-old unchanging use case can be done in a new way doesn't mean it has to be reinvented every time you turn around. Especially if it just makes everything slower (and you keep telling me the whole reason you did it this way is for speed )
|
|
# ? Jul 6, 2016 17:54 |
|
Data Graham posted:
Well, to be fair, if you are using React, only it should me messing w/ the DOM, so you shouldn't use jQuery's DOM manipulation in that case... and if you aren't using it for that, there is little point in using in these days. It's been years since I used jQuery, even in a non-React project. I guess if I had to support IE8 I might still.
|
# ? Jul 6, 2016 18:54 |
Right, I mean either I'm going whole-hog client-side templating (Angular/React/what-have-you), or I'm rolling my own workflow via jQuery. I still find the latter to be just as flexible and a lot easier for new team members to pick up quickly a lot of the time. Just means you're doing more stuff explicitly, which isn't necessarily a bad thing if the alternative is spending weeks spelunking through clever MVC stuff.
|
|
# ? Jul 6, 2016 18:57 |
|
Does jQuery's $.ajax() offer any particularly compelling benefits over doing XHR "manually"?
|
# ? Jul 7, 2016 02:43 |
|
Does anyone know how well Angular's form validation works with HTML5 form validation? The new SCA that we have to run all of our web apps against with some special client-mandated security definitions thinks that turning off HTML5 form validation is as equally dangerous as allowing SQL injection. I really don't want to go through and do regression tests on the 50-60 forms in our application to see if the forms all work the same.
|
# ? Jul 7, 2016 03:32 |
|
Anony Mouse posted:Does jQuery's $.ajax() offer any particularly compelling benefits over doing XHR "manually"? A few hundred lines less code, some interesting bug 'fixes' like https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js#L21, easier to use if you plan on having a lot of options?
|
# ? Jul 7, 2016 04:46 |
|
Anony Mouse posted:Does jQuery's $.ajax() offer any particularly compelling benefits over doing XHR "manually"?
|
# ? Jul 7, 2016 08:35 |
|
I'm in more of a development role than a graphics role, but have had to do some stuff lately without Photoshop and.... Paint.net is really good guys. So far I've had to do these kind of one offs: - Edit/crop/adjust product photos - Make animated gifs - Make favico - Make simple pre-press print things (instruction cards, logos, coupon drop cards, etc.) The only thing I miss/need Photoshop for is: - Advanced text (kerning, text along path, etc.) - Angular lasso select for removing backgrounds Everything else Paint.net does easily and well. Kinda impressed to tell the truth, makes me wonder why I've been wrestling with Gimp all these years and can still barely do anything in it.
|
# ? Jul 7, 2016 18:36 |
|
Anony Mouse posted:Does jQuery's $.ajax() offer any particularly compelling benefits over doing XHR "manually"? Others have said the stuff I would say mostly, but I wanted to add that the new fetch api is pretty nice and there's a good polyfill for older browsers.
|
# ? Jul 7, 2016 18:47 |
|
Scaramouche posted:...why I've been wrestling with Gimp all these years and can still barely do anything in it. Because the UI for the GIMP is a poster child for everything you can do wrong.
|
# ? Jul 7, 2016 19:08 |
|
Scaramouche posted:I'm in more of a development role than a graphics role, but have had to do some stuff lately without Photoshop and.... Paint.net is really good guys. So far I've had to do these kind of one offs:
|
# ? Jul 7, 2016 20:05 |
|
Seconding Sketch. I too sometimes have to create "programmer art" and just did a bunch of OS X app toolbar icons in it. Far easier and far more enjoyable than in Adobe products (for which I do have a CC subscription). They have a bunch of instructional videos on their site which I found very useful and which actually helped convince me to buy it.
|
# ? Jul 7, 2016 20:13 |
argondamn posted:Does anyone know how well Angular's form validation works with HTML5 form validation? The new SCA that we have to run all of our web apps against with some special client-mandated security definitions thinks that turning off HTML5 form validation is as equally dangerous as allowing SQL injection. I really don't want to go through and do regression tests on the 50-60 forms in our application to see if the forms all work the same. Well, my question #1 would be, are you doing input validation on the server side too? Because relying on any kind of client-side input sanitation is basically leaving the door wide open to anyone with a script.
|
|
# ? Jul 8, 2016 01:38 |
Data Graham posted:Well, my question #1 would be, are you doing input validation on the server side too? Saves round trips to the server, faster experience for the client. Doesn't seem like a bad idea to have both.
|
|
# ? Jul 8, 2016 02:24 |
Yeah, hence "too". I meant that encouragingly, not disparagingly.
|
|
# ? Jul 8, 2016 02:28 |
Data Graham posted:Yeah, hence "too". I meant that encouragingly, not disparagingly. Oops, my brain read that as "why are you doing..."
|
|
# ? Jul 8, 2016 02:29 |
|
Thermopyle posted:Others have said the stuff I would say mostly, but I wanted to add that the new fetch api is pretty nice and there's a good polyfill for older browsers. This. Fetch is great. https://github.com/github/fetch
|
# ? Jul 8, 2016 03:16 |
|
Data Graham posted:Yeah, hence "too". I meant that encouragingly, not disparagingly. It also means there is no reason for HTML5 Validation to be part of a security audit, because it has precisely zero to do with security and may mess up some behaviors of your forms. It'll probably be fine, but obviously if you drop in something you would do well to test your forms.
|
# ? Jul 8, 2016 06:20 |
|
Anony Mouse posted:If you're on Mac, check out Sketch. I was skeptical at first but it has won me over along with the rest of my studio. We use it for everything from wireframes to visual design production to redlining. $99 for a perpetual license is dirt cheap compared to Adobe's subscription bullshit. My life revolves around Sketch but it's more akin to Illustrator than Photoshop. Its bitmap tools are rudimentary at best.
|
# ? Jul 8, 2016 06:20 |
|
One of our clients continuously complains about getting spam through the contact form on their site. The problem is the HTML and, more importantly, the action for the form is generated and handled by their CRM so we've got no hand in processing submissions. I've added reCaptcha on the client-side but that's pretty easy to bypass, are there any options for reducing spam when they won't let us handle the forms? I thought about processing submissions on our server then POSTing them on to the client CRM - is this a crazy idea?
|
# ? Jul 8, 2016 10:15 |
|
Kobayashi posted:My life revolves around Sketch but it's more akin to Illustrator than Photoshop. Its bitmap tools are rudimentary at best.
|
# ? Jul 8, 2016 18:20 |
|
nexus6 posted:One of our clients continuously complains about getting spam through the contact form on their site. The problem is the HTML and, more importantly, the action for the form is generated and handled by their CRM so we've got no hand in processing submissions. Can you throttle submissions per client IP? If you can't via their CRM... I can think of a few crazy ways to do with JavaScript that would probably catch most spammers.
|
# ? Jul 8, 2016 21:11 |
How permeable is reCaptcha? I was under the impression (from a quick search) that the latest version is pretty good.
|
|
# ? Jul 8, 2016 21:24 |
|
Skandranon posted:Can you throttle submissions per client IP? I don't have access to their CRM at all
|
# ? Jul 8, 2016 22:10 |
|
Data Graham posted:How permeable is reCaptcha? I was under the impression (from a quick search) that the latest version is pretty good. one of the tools i've seen recently cracks recaptcha by running each image through google reverse image search and scores pretty well on fully automating recaptcha challenges for the grid of images also, nexus6 posted:
recaptcha requires a server-side portion too, or it's completely useless and the point is moot; you can't just "bypass" it unless you are actually not checking recaptcha at all server side
|
# ? Jul 8, 2016 22:53 |
|
nexus6 posted:I don't have access to their CRM at all
|
# ? Jul 8, 2016 23:18 |
|
Data Graham posted:Well, my question #1 would be, are you doing input validation on the server side too? Because relying on any kind of client-side input sanitation is basically leaving the door wide open to anyone with a script. Of course. Thankfully I've been able to convince my way too involved PL to let me mark it as "Not an issue" and move on. Funny thing is all the severe findings were false positives and the one actual security risk (XSRF) was just a moderate finding.
|
# ? Jul 8, 2016 23:38 |
|
root beer posted:You could add an additional form field that resides inside of a hidden <div> within your form. Then, add some JS to either prevent the form from submitting if it has content, or updates the post action to point to a blank page.
|
# ? Jul 8, 2016 23:58 |
|
Anony Mouse posted:Does this kind of thing actually work? I mean, it seems kind of rudimentary to be honest and too easy to programmatically determine which is the "actual" form. Yeah, but that requires someone to spend actual effort and attention on your site. Most people are probably using canned tools and will give up very quickly when it doesn't work. You don't have to be faster than the bear, just faster than someone else running away.
|
# ? Jul 9, 2016 00:40 |
|
Anony Mouse posted:Does this kind of thing actually work? I mean, it seems kind of rudimentary to be honest and too easy to programmatically determine which is the "actual" form. It works a lot better if you can modify how the form is processed on the server side (so that you can actually change the names of processed fields to remove keywords bots look for), but it's really more of a bandaid-on-cancer type of deal.
|
# ? Jul 9, 2016 00:50 |
|
Anony Mouse posted:Does this kind of thing actually work? I mean, it seems kind of rudimentary to be honest and too easy to programmatically determine which is the "actual" form. I've got one set up like that where it's "Email" <hidden div><input name="email"></div><input name="optionalfield1">, but the amount of spam getting through it has increased notably in the last six months so I think there's at least one tool that has figured it out.
|
# ? Jul 9, 2016 05:43 |
|
All of those "clever tricks" you try to fool spambots with are basically just an easy way to make your site completely unusable by anyone that relies on a screen reader or other assistive technology in order to use their computer. Please don't do that.
|
# ? Jul 9, 2016 10:50 |
|
Jabor posted:All of those "clever tricks" you try to fool spambots with are basically just an easy way to make your site completely unusable by anyone that relies on a screen reader or other assistive technology in order to use their computer. Please don't do that. What are your alternatives?
|
# ? Jul 9, 2016 10:56 |
|
Heskie posted:What are your alternatives? To: Client From: You Subject: Re: WHY ARE WE GETTING SO MCUH SPAM!!!!1!!` "Now that we've installed reCAPTCHA on the form you should see significantly less spam. However please be aware that since this is a public form on the internet you will always see a certain amount of spam and there's simply no way around that." Seriously, there's no silver bullet. I've avoided this argument with clients for years by telling them to expect to see spam before I create a form, while I'm creating the form, and occasionally after I've created the form. Also anecdotally, I have a site where forms are hidden with CSS until a user clicks a "I want to fill out the form" button, and they have never seen a lick of spam. No captcha, lots of traffic. Granted it's a pretty special use case and I wouldn't recommend it in general.
|
# ? Jul 9, 2016 13:21 |
The site I just rolled out, I dutifully made sure the entire two-tier ajaxy form worked fine with no-JavaScript fallback. Took a lot of effort and testing, too. I was super proud of it. But then I had to add recaptcha, and... well. No more using the site without JS.
|
|
# ? Jul 9, 2016 15:28 |
|
I need some help with displaying different content in different view sizes, and I believe it's not something I can do with media queries via css. I'm using Angular 1.5.x + Angular-Bootstrap + some modules from AngularStrap. I am using a dropdown in my navbar and it works great for a desktop presentation, however on mobile I need to change the dropdown to a different format. Right now I'm trying to gently caress it through DOM manipulation as so: code:
Another problem I am having is that when I switch back to Desktop size it doesn't replace the changed content back to desktop version, it leaves the mobile data in the DOM until I click on something then it switches. Additionally there's a delay of 1-2 seconds to actually switch the template. Advice is seriously welcome how I can do this. Is there a way I could accomplish this via ui.router or another way that seems less hackish? Edit: Yes I know I'm not using Typescript. Still learning that. I'd be happy if someone showed me in Typescript because I have the transpiler set up for it. Edit 2: It feels like ui.bootstrap and AngularStrap just add unnecessary complications, but it's the best way right? ModeSix fucked around with this message at 21:42 on Jul 10, 2016 |
# ? Jul 10, 2016 21:23 |
|
|
# ? Jun 5, 2024 09:28 |
|
Data Graham posted:The site I just rolled out, I dutifully made sure the entire two-tier ajaxy form worked fine with no-JavaScript fallback. Took a lot of effort and testing, too. I was super proud of it. But then I had to add recaptcha, and... well. No more using the site without JS. recaptcha supports non-javascript clients iirc? you basically get text to copy paste into a plain <input> field
|
# ? Jul 10, 2016 22:43 |