The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›362 »

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I've been working on a service that generates email addresses (incoming only) and another thing that lets you generate free forums and I'm 80% certain the first thing I'm going to do is block Europe.

# ? Jan 11, 2019 01:33

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 06:23

MrMoo: Sep 14, 2000

Munkeymon posted:

Instead of a new window or page navigation, put up a modal containing an iframe with that URL?

Or open the window first with an interstitial screen and redirect when you have the real target. :lol:

# ? Jan 11, 2019 02:37

Boris Galerkin: Dec 17, 2011; I don't understand why I can't harass people online. Seriously, somebody please explain why I shouldn't be allowed to stalk others on social media!

Edit: didn�t see there was a database thread

# ? Jan 11, 2019 07:17

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Munkeymon posted:

Instead of a new window or page navigation, put up a modal containing an iframe with that URL?

Well, got this working very quickly: fired up my phone to test, and Facebook sets X-FRAME-OPTIONS: DENY , which my phone browser respects, but my desktop firefox apparently does not, which is why it worked there....

So looks like redirects and having the user reload the entire SPA and whatnot :smith:

# ? Jan 11, 2019 15:13

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

I'm working on an app and had hoped to get away with a static site communicating directly with a CouchDB database, with CouchDB managing user authentication, etc. I'm hitting roadblocks with respect to creating space for data that multiple users should have access to. My original notion was to create individual databases for data shared by Andy, Beth and Carl, but it turns out that regular logged-in users aren't capable of creating new dbs.

I'll need a server with admin rights to achieve this aim.

My couchdb server is running on a digital ocean droplet. Any recommendations on a dead-simple server layer that can take requests from my static site and then hit my CouchDB instance (same droplet) with http requests?

e: basic workflow as follows:

- client-side js makes a call to my server layer, passing some json with request details (and auth info)
- server layer checks the user's auth, and then makes changes to the couchdb using hard-coded admin credential
- server layer returns some result to the browser
- client goes about its business

From what I can tell, I can do this with a single file via express.js. Any reason not to go that route?

Newf fucked around with this message at 07:55 on Jan 13, 2019

# ? Jan 13, 2019 05:05

Dominoes: Sep 20, 2007

Hey dudes. How do you handle POST data in pure HTML or JSX? I'm trying to download a file, which doesn't seem to work with fetch requests. I've been using something like this for get requests, but when adapted to POST, not sure how to send the body data. The MDN docs indicate something like this, where you just put it in there (STS) but it neither looks right, nor works.

code:

            <form action="/export-week-schedule/" method="post" style={{width: '100%'}}>
                <DjangoCSRFToken />
                date: {schedulesToShow[0][0]}
                <button style={{}}
                        className="btn btn-default" type="submit">
                    Export to Excel
                </button>
            </form>

Dominoes fucked around with this message at 22:36 on Jan 15, 2019

# ? Jan 15, 2019 22:34

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

Dominoes posted:

Hey dudes. How do you handle POST data in pure HTML or JSX? I'm trying to download a file, which doesn't seem to work with fetch requests. I've been using something like this for get requests, but when adapted to POST, not sure how to send the body data. The MDN docs indicate something like this, where you just put it in there (STS) but it neither looks right, nor works.
code:
            <form action="/export-week-schedule/" method="post" style={{width: '100%'}}>
                <DjangoCSRFToken />
                date: {schedulesToShow[0][0]}
                <button style={{}}
                        className="btn btn-default" type="submit">
                    Export to Excel
                </button>
            </form>

Uh, you mean you just want to make the browser POST a plain old form like it's the 1990's? application/x-www-form-urlencoded? In that case the body is constructed from the <input> tags in the form, and if you don't want the user to muck with them, you can use hidden ones, like so:

code:

<form action="/export-week-schedule/" method="post">
  <input type="hidden" name="date" value="your data goes here">
  <button type="submit">mash this</button>
</form>

If you just want a file download you can also just make a plain ol' link, just make sure to set the content-disposition header properly on the server.

TheFluff fucked around with this message at 22:49 on Jan 15, 2019

# ? Jan 15, 2019 22:45

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Do you really want to use html? If you want to just use javascript it's no problem with FormData and XMLHttpRequest...

https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects

# ? Jan 15, 2019 23:34

Dominoes: Sep 20, 2007

Thanks a lot - that worked! This feels super-hacky (Plus clumsy, as is typical for handling forms etc with Django directly), but I'm not sure how else to handle the case of files I'm generating on the server.

edit: Nolg - that might be what I really need.

# ? Jan 15, 2019 23:56

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

Dominoes posted:

Thanks a lot - that worked! This feels super-hacky (Plus clumsy, as is typical for handling forms etc with Django directly), but I'm not sure how else to handle the case of files I'm generating on the server.

edit: Nolg - that might be what I really need.

It's how we did it for decades :shrug:

XMLHTTPRequest will not trigger a file download dialog in the browser either, as far as I know. Again, I'd say the cleanest way of doing this would probably be to just use a regular link (unless you really need to pass a complex object as a parameter to the file generating code on the server) instead of posting a form. If you want hacky though, you can first get the file to a javascript variable with the fetch API, then use URL.createObjectURL to store it in a URL (like, "data:<base64>") and finally pass that to window.open to get the browser to download it (and don't forget to revoke the data URL afterwards). Don't do that though, it's silly.

TheFluff fucked around with this message at 00:16 on Jan 16, 2019

# ? Jan 16, 2019 00:11

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

You really just want to set window.location.href to the file location and let their browser do what it does with the filetype. In most cases it'll download. I did something really hacky for a tampermonkey script I use to download images sometimes, it involves creating a link element setting the href to a data url, setting a "download" attribute to the filename I want and triggering a click event on it.

But it's so incredibly hacky I'm ashamed of it so I won't post the code. I have no idea if it works anywhere other than firefox.

# ? Jan 16, 2019 01:42

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Nolgthorn posted:

You really just want to set window.location.href to the file location and let their browser do what it does with the filetype. In most cases it'll download.

Just to elaborate, this depends on the content-disposition header returned by the server. 'attachment' will make it prompt to save, 'inline' will attempt to display it in the browser.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition

# ? Jan 16, 2019 03:41

SnatchRabbit: Feb 23, 2006; by sebmojo

I'm building a management page for some of my AWS resources using html and javascript. I've populated a table with some data I'm fetching from lambda but there's two features I'm kind of stumped on, not sure what elements I should be using. The first is I need the table to be selectable so that I can click on a particular resource and fire off an api call. The second is I need some sort of text output field where I can post status messages like, instance is rebooting, instance has been terminated, etc. Is there a particular good resource/tool/element I should be looking at? I'm not all that great with web front ends so any help would be appreciated.

# ? Jan 16, 2019 18:38

Tei: Feb 19, 2011

TheFluff posted:

It's how we did it for decades

XMLHTTPRequest will not trigger a file download dialog in the browser either, as far as I know. Again, I'd say the cleanest way of doing this would probably be to just use a regular link (unless you really need to pass a complex object as a parameter to the file generating code on the server) instead of posting a form. If you want hacky though, you can first get the file to a javascript variable with the fetch API, then use URL.createObjectURL to store it in a URL (like, "data:<base64>") and finally pass that to window.open to get the browser to download it (and don't forget to revoke the data URL afterwards). Don't do that though, it's silly.

What you suggest may look like this:

quote:

var blob = new Blob([arrayBuffer],{type:"application/octet-binary"});
var url = URL.createObjectURL(blob);

var a = document.createElement("a");
a.innerHTML = "-descarga-";
$(a).attr("download",spec.name);
$(a).attr("href",url);

I tried the above in a application I made and since it worked, I did not look further, but I believe theres a even better way to do it.

Heres another example:
https://stackoverflow.com/questions/19327749/javascript-blob-filename-without-link

Reading about it a litte I notized "Blobs" is like some sort of cache the browser create, that you can access and use to store data. "Blob urls" are first class citizens in Brownserland and probably will allow some really cool poo poo we just can't imagine.

Tei fucked around with this message at 18:58 on Jan 16, 2019

# ? Jan 16, 2019 18:48

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

SnatchRabbit posted:

I'm building a management page for some of my AWS resources using html and javascript. I've populated a table with some data I'm fetching from lambda but there's two features I'm kind of stumped on, not sure what elements I should be using. The first is I need the table to be selectable so that I can click on a particular resource and fire off an api call. The second is I need some sort of text output field where I can post status messages like, instance is rebooting, instance has been terminated, etc. Is there a particular good resource/tool/element I should be looking at? I'm not all that great with web front ends so any help would be appreciated.

The good news is the tools you should use are HTML and javascript. You can add event handlers to any element, so your table is by default "selectable" and you can use JS to change the contents of any element. You can fire off API calls using the "fetch" API on click, then update your message element as things happen.

JavaScript code:

clickHandler = event => {
   // use the event object to tell what TR or TD the user clicked on if you aren't
   // using element specific handlers
   const msgBox = document.getElementById('myMessageBox');
   msgBox.innerText = 'I am doing a thing...';
   fetch( someAPIURL ).then( result => {
      // inspect the result or whatever
      msgBox.innerText = 'Things went swimmingly';
      // probably update your table row that the click came from.
   }).catch( error => {
      // inspect he error maybe
      msgBox.innerText = 'OH NO!!';
   })
}

Lumpy fucked around with this message at 19:02 on Jan 16, 2019

# ? Jan 16, 2019 18:59

my bony fealty: Oct 1, 2008

I am looking for a way to persist data between two separate front-end sites. Like a user completes one and clicks a button that directs them to the other, which is aware of what they entered in the first.

Currently using localStorage but it seems...unreliable. some of the testers say it doesnt work and I dunno why.

Whats a good option here - a cookie? Session storage? window.name like mentioned earlier? Whatever it is will be in addition to local storage since that works sometimes and multiple layers of redundancy seems good.

Might resort to just using MongoDB or somesuch as I do not really trust the browser for reliable persistent storage right now :shrug:

# ? Jan 16, 2019 19:25

SnatchRabbit: Feb 23, 2006; by sebmojo

Lumpy posted:

The good news is the tools you should use are HTML and javascript. You can add event handlers to any element, so your table is by default "selectable" and you can use JS to change the contents of any element. You can fire off API calls using the "fetch" API on click, then update your message element as things happen.
JavaScript code:
clickHandler = event => {
   // use the event object to tell what TR or TD the user clicked on if you aren't
   // using element specific handlers
   const msgBox = document.getElementById('myMessageBox');
   msgBox.innerText = 'I am doing a thing...';
   fetch( someAPIURL ).then( result => {
      // inspect the result or whatever
      msgBox.innerText = 'Things went swimmingly';
      // probably update your table row that the click came from.
   }).catch( error => {
      // inspect he error maybe
      msgBox.innerText = 'OH NO!!';
   })
}

Thanks, that helps. In terms of selecting data from the table, does it matter that I am dynamically generating the table data from a mustache template?

# ? Jan 16, 2019 19:57

Tei: Feb 19, 2011

my bony fealty posted:

I am looking for a way to persist data between two separate front-end sites. Like a user completes one and clicks a button that directs them to the other, which is aware of what they entered in the first.

Currently using localStorage but it seems...unreliable. some of the testers say it doesnt work and I dunno why.

I believe Single Sign On technologies allow to have a session that spans multiple sites, so different sites can access the same session data. And sessions stored in a database are basically persistent.

If your setup is really two different sites, localStorage should only be reachable by one, and not the other. I believe this can only work, or not work. Is weird that you say your testers say that is unreliable. localStorage probably have some solid and wide support, and if it works, it would be really useful.

A dumb SSO setup would be

Site Storage: store.com
Site A: sitea.com
Site B: siteb.com

Link from A to B
http://siteb.com/whatever.php?session=3232323

Link from B to A
http://siteb.com/something.php?session=3232323

On SiteA you sets name=luis
http://store.com/store.php?session=3232323&mode=set&key=name&value=luis

....

Site B request the name value
http://store.com/print_results.php?session=3232323&mode=get&key=name
this return "luis".

A user visiting either A or B would need to adquire a new session, or open a old one.
I believe building this "session system that is not limited to a single host" would be fun, but if you can really use localStorage, it would save you time.

Note: Calling store.com from sitea.com or siteb.com would require store.com to declare all ajax are wellcome.

# ? Jan 16, 2019 20:13

The Fool: Oct 16, 2003

Tei posted:

I believe Single Sign On technologies allow to have a session that spans multiple sites, so different sites can access the same session data. And sessions stored in a database are basically persistent.

If your setup is really two different sites, localStorage should only be reachable by one, and not the other. I believe this can only work, or not work. Is weird that you say your testers say that is unreliable. localStorage probably have some solid and wide support, and if it works, it would be really useful.

A dumb SSO setup would be

Site Storage: store.com
Site A: sitea.com
Site B: siteb.com

Link from A to B
http://siteb.com/whatever.php?session=3232323

Link from B to A
http://siteb.com/something.php?session=3232323

On SiteA you sets name=luis
http://store.com/store.php?session=3232323&mode=set&key=name&value=luis

....

Site B request the name value
http://store.com/print_results.php?session=3232323&mode=get&key=name
this return "luis".

A user visiting either A or B would need to adquire a new session, or open a old one.
I believe building this "session system that is not limited to a single host" would be fun, but if you can really use localStorage, it would save you time.

Note: Calling store.com from sitea.com or siteb.com would require store.com to declare all ajax are wellcome.

This is "Identity Federation" and is a very deep well.

# ? Jan 16, 2019 20:17

Tei: Feb 19, 2011

"Identity Federation" is a cool name, so I am ok with calling it that.

I believe a simple system could be made with about 30 lines of code.
But of course, some people have probably write 30 million lines to provide the same feature.

Tei fucked around with this message at 20:42 on Jan 16, 2019

# ? Jan 16, 2019 20:35

my bony fealty: Oct 1, 2008

Thanks for that, I will investigate. Should have mentioned that these sites are hosted as subdirectories of the same domain so they have access to the same local storage.

Trying to wire up front end things that need back endish stuff without a proper backend available is fun :unsmith:

# ? Jan 16, 2019 20:43

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Problems with local storage:
- Opera mini doesn't like it? I think Safari as well
- Storage doesn't persist if Incognito/Private is used, though it will work within that session
- Clearing cache obviously wipes it
- Aggressive Content Settings policies can prevent using it
- Content in it is pretty well insecure and can be accessed by anything that CSP allows to run on the page
- Calls to local storage are synchronous (e.g. non-performant), doesn't support complex non-string data types

# ? Jan 16, 2019 21:20

huhu: Feb 24, 2006

my bony fealty posted:

.

Trying to wire up front end things that need back endish stuff without a proper backend available is fun

Can you not make a case for a backend?

# ? Jan 16, 2019 22:17

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

my bony fealty posted:

I am looking for a way to persist data between two separate front-end sites. Like a user completes one and clicks a button that directs them to the other, which is aware of what they entered in the first.

Currently using localStorage but it seems...unreliable. some of the testers say it doesnt work and I dunno why.

Whats a good option here - a cookie? Session storage? window.name like mentioned earlier? Whatever it is will be in addition to local storage since that works sometimes and multiple layers of redundancy seems good.

Might resort to just using MongoDB or somesuch as I do not really trust the browser for reliable persistent storage right now

Do different domains have access to the same local storage? I don't believe so.

The way to do this is to maintain session, and, session information, server side. And have the server willing to communicate with both websites. The problem you will face server side is the same reason why clients don't support this by default, which is security. How do you ensure the person visiting the other domain is the same person?

I think you need a server for each domain, and you need those servers to communicate with each other. Where you can make a request to the domain you are on, which handles the redirection, generating a session identifier for the other domain, so that you know it's the same user.

# ? Jan 16, 2019 22:43

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

GET /redirect-me-please

Server takes a look at your existing session, stores it somewhere or sends it to the other server. Redirects you to /redirect-callback?sid=80801010101010.

GET /redirect-callback?sid=80801010101010

Other server looks up your sid in storage, compares the storage date against a 6 second expiry, gathers your data together on its domain and generates your new session containing data from the other domain and redirects you to whatever you wanted them to land on. You can have as many query parameters defining this behaviour as you want but I don't think it can be any simpler than that.

Even better would be using JWT, and signing it with asymmetric keys. So that you don't need a "magic key" that'll subvert your application, but instead a key from each server, which would be twice as hard to get.

# ? Jan 16, 2019 22:53

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

If you go the JWT route you won't need server side storage of the session which is even better really, because it's simpler as long as you understand how JWT works. You can just include all that data in the token itself and pass it to the other server as a query parameter. As long as the signature is valid you can trust the contents of the token and you're golden.

# ? Jan 16, 2019 23:08

Tei: Feb 19, 2011

Scaramouche posted:

Problems with local storage:
- Opera mini doesn't like it? I think Safari as well
- Storage doesn't persist if Incognito/Private is used, though it will work within that session
- Clearing cache obviously wipes it
- Aggressive Content Settings policies can prevent using it
- Content in it is pretty well insecure and can be accessed by anything that CSP allows to run on the page
- Calls to local storage are synchronous (e.g. non-performant), doesn't support complex non-string data types

You are not wrong, is not a perfect thing. Anyway let me comment your comment:

Opera mini can gently caress itself with a red hot iron bar.
Safari have problems with it? I have not heard it.

The incognito mode is more a matter of concern, more because a user may activate it accidentally (is too easy in Safari/iPhone). Anyway if you can detect that, you can ask the user nicely "Incognito mode is not compatible with this app, please use normal mode".

Content is insecure, welp, yea. Could be sniffed by banners, so if your site is important to be targeted, can be a problem. If you are small, is moot point.
Local storage asyncronous and nonperformant, I don't think can byte back hard. But this may prove very wrong later :-/
Not supporting complex problem is not a problem, since you can serialize.

# ? Jan 16, 2019 23:25

my bony fealty: Oct 1, 2008

huhu posted:

Can you not make a case for a backend?

Yeah, it would take a long time though if it got approved. Luv 2 be "agile." I do have the power to use a service like mLab or Mongo Atlas or probably AWS without bothering the backend folks tho so that might be a solution. Thankfully free tier will be good enough for this.

JWT is very intriguing. Will look into that as well.

# ? Jan 16, 2019 23:55

the heat goes wrong: Dec 31, 2005; I´m watching you...

Unless I'm missing something with the file download chat, why not simply use a normal link with download attribute added?

<a href="/filez/notavirus.jpg" download>

# ? Jan 17, 2019 09:47

Tei: Feb 19, 2011

the heat goes wrong posted:

Unless I'm missing something with the file download chat, why not simply use a normal link with download attribute added?

<a href="/filez/notavirus.jpg" download>

I think this have more to do with clientside apps that are generating the data themselves, not downloading it from a server.

You don't need what you suggest if you control the server, just just deliver the file with a fun mime type, like octect/stream.

# ? Jan 17, 2019 14:07

Cugel the Clever: Apr 5, 2009; I LOVE AMERICA AND CAPITALISM DESPITE BEING POOR AS FUCK. I WILL NEVER RETIRE BUT HERE'S ANOTHER 200$ FOR UKRAINE, SLAVA

Stupid question: we're sending along cookies with every XHR request to an ending so they can determine whether the user is logged in or not, which amounts to 3+ kb included in each request (potentially repeated a few times a minute)--is it worth bothering parsing out the user's authentication status in the browser and simply sending that value instead of the heap of cookies? Or would that be a micro-optimization that isn't even worth bothering with? Or are there other problems I'm not even seeing?

Thinking mainly for performance for users with a slow/spotty connection. Don't really have a scope for what can be done to improve their user experience.

# ? Jan 17, 2019 16:01

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Cugel the Clever posted:

Stupid question: we're sending along cookies with every XHR request to an ending so they can determine whether the user is logged in or not, which amounts to 3+ kb included in each request (potentially repeated a few times a minute)--is it worth bothering parsing out the user's authentication status in the browser and simply sending that value instead of the heap of cookies? Or would that be a micro-optimization that isn't even worth bothering with? Or are there other problems I'm not even seeing?

Thinking mainly for performance for users with a slow/spotty connection. Don't really have a scope for what can be done to improve their user experience.

not that i have enough background from your question, but we had a similar problem because we're using identity server / token auth, and we were putting JWT tokens in the cookie - a JWT token contains all the claims etc stringified and base64ed and is pretty big, so it was a big cookie.

we switched over to using reference (opaque) tokens, which is basically a handle to the token rather than the token itself - so the cookie would just contain a handle, claims would be stored in database, api gets claims from validation endpoint when necessary.

the advantage here is instead of sending the 3k cookie, you're just sending a guid. this also allows you to invalidate the request on logout and prevent spoofing the request.

# ? Jan 17, 2019 16:18

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Tei posted:

Safari have problems with it? I have not heard it.

Well, I know if it's in Incognito, Safari will say it supports localstorage, but then not actually do anything with it. So to get around that, I test it with this:

code:

var isLocalStorageNameSupported = function() {
    var testKey = 'test', storage = window.sessionStorage;
    try {
      storage.setItem(testKey, '1');
      storage.removeItem(testKey);
      return true;
    } catch (error) {
      return false;
    }
  }

Also, I know Safari is more aggressive in removing locally stored data from a device, but that might only pertain to PWA and service workers.

# ? Jan 17, 2019 16:33

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

SnatchRabbit posted:

Thanks, that helps. In terms of selecting data from the table, does it matter that I am dynamically generating the table data from a mustache template?

Nope. Just make sure you have a way to ID the element / pass the data to your function(s). You can do this a number of ways and which one you choose will vary based on your needs. If you are adding & removing rows during the life of the page frequently, you may want to a handler on the table itself, and inspect the event.target to see if it came from a row / td and use data attributes to pass info. If the table is generated on load, or just once without much adding / removing, you may find adding inline handlers easier.

# ? Jan 17, 2019 19:10

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Tei posted:

You are not wrong, is not a perfect thing. Anyway let me comment your comment:

Opera mini can gently caress itself with a red hot iron bar.
Safari have problems with it? I have not heard it.

The incognito mode is more a matter of concern, more because a user may activate it accidentally (is too easy in Safari/iPhone). Anyway if you can detect that, you can ask the user nicely "Incognito mode is not compatible with this app, please use normal mode".

Content is insecure, welp, yea. Could be sniffed by banners, so if your site is important to be targeted, can be a problem. If you are small, is moot point.
Local storage asyncronous and nonperformant, I don't think can byte back hard. But this may prove very wrong later :-/
Not supporting complex problem is not a problem, since you can serialize.

Yeah I wasn't saying "don't ever ever use it" but more giving a list of gotchas that can be a problem if you do decide to use it. There are actual legit use cases for Local Storage though, but they're not as many as you'd initially think.

# ? Jan 17, 2019 19:11

Tei: Feb 19, 2011

I really want to use the type of features that serviceworkers provide. But it require HTTPS, that I hate, and is overengineered by the most obvious abuse of complicator gloves.

To the people that designed how service workers function: Please stop doing abstraction leaking in the browser. We don't need to know how it work internally. gently caress you.

# ? Jan 17, 2019 20:27

Tei: Feb 19, 2011

I want to extend the "gently caress you" to the people that push HTTPS so strongly, as to put "No secure" to any form in HTTP.

More because I can get a certificate to sign my site. But for whatever reason I can't use that certificate to sign other things. Creating a chain of signatures.

How this whole thing is designed, is moronic, overcomplicated and fragile has hell.

# ? Jan 17, 2019 20:30

The Fool: Oct 16, 2003

Most of your posts are good and on point, but this is the second time I've seen you spout a bad and wrong opinion about https.

# ? Jan 17, 2019 21:07

Tei: Feb 19, 2011

The Fool posted:

Most of your posts are good and on point, but this is the second time I've seen you spout a bad and wrong opinion about https.

The current fad is "if is HTTP is not safe" and thats magical thinking. Not everything need to be HTTPS. And not everything is a credit card form.

Some cool features are kidnapped and put behind HTTPS, not because these features need it, just to force people into paying certificated, and push the web to more centralism.

I have a lot of bad opinions, and I hope I am wrong here again.

# ? Jan 17, 2019 21:17

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 06:23

kedo: Nov 27, 2007

Why wouldn't you want to use https? It's brainlessly simple to set up an SSL cert with Let's Encrypt, and it offers at least a bare minimum amount of protection for your users who might be accessing your site on an unsecured network or through an ISP with nefarious privacy policies.

e:

Tei posted:

The current fad is "if is HTTP is not safe" and thats magical thinking. Not everything need to be HTTPS. And not everything is a credit card form.

Some cool features are kidnapped and put behind HTTPS, not because these features need it, just to force people into paying certificated, and push the web to more centralism.

Let's Encrypt is free. So are many other completely legitimate SSL certifiers. https of course isn't absolutely necessary for many projects, but there's no good excuse not to use it, and there are a ton of other reasons to use https besides preventing credit card fraud.

kedo fucked around with this message at 21:24 on Jan 17, 2019

# ? Jan 17, 2019 21:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›362 »