|
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 |
|
|
# ? Jun 5, 2024 05:12 |
|
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.
|
# ? Jan 11, 2019 02:37 |
|
Edit: didn’t see there was a database thread
|
# ? Jan 11, 2019 07:17 |
|
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
|
# ? Jan 11, 2019 15:13 |
|
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 |
|
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:
Dominoes fucked around with this message at 22:36 on Jan 15, 2019 |
# ? Jan 15, 2019 22:34 |
|
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:
TheFluff fucked around with this message at 22:49 on Jan 15, 2019 |
# ? Jan 15, 2019 22:45 |
|
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 |
|
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 |
|
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. 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. TheFluff fucked around with this message at 00:16 on Jan 16, 2019 |
# ? Jan 16, 2019 00:11 |
|
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 |
|
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 |
|
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 |
|
TheFluff posted:It's how we did it for decades What you suggest may look like this: quote:var blob = new Blob([arrayBuffer],{type:"application/octet-binary"}); 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 |
|
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:
Lumpy fucked around with this message at 19:02 on Jan 16, 2019 |
# ? Jan 16, 2019 18:59 |
|
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
|
# ? Jan 16, 2019 19:25 |
|
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. 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 |
|
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. 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 |
|
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. This is "Identity Federation" and is a very deep well.
|
# ? Jan 16, 2019 20:17 |
|
"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 |
|
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
|
# ? Jan 16, 2019 20:43 |
|
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 |
|
my bony fealty posted:. Can you not make a case for a backend?
|
# ? Jan 16, 2019 22:17 |
|
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. 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 |
|
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 |
|
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 |
|
Scaramouche posted:Problems with local storage: 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 |
|
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 |
|
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 |
|
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? 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 |
|
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 |
|
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? 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 |
|
Tei posted:Safari have problems with it? I have not heard it. code:
|
# ? Jan 17, 2019 16:33 |
|
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 |
|
Tei posted:You are not wrong, is not a perfect thing. Anyway let me comment your comment: 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
|
# ? Jun 5, 2024 05:12 |
|
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. 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 |