here is my problem: It would be great if users could not only share the link to my website, but also the values they entered there. So far, so good.
First try: simply submit values by GET.
Does not work because: if the URL is
domain.com?param1=a¶m2=b
then simply the part before the ? will be shared (at least on iPhones, but that's bad.) So they just share
domain.com
and no parameters are sent. (Google told me the same without giving me a proper workaround idea.)
Okay. Second try: Some workaround involving .htaccess and history.pushstate. It worked quite well, but history.pushstate does not seem to affect the shared URL on iPhones either.
That's bad so far. Does maybe anyone have an idea what to use to solve my problem? Thank you very much :)
It is correct to share domain.com?param1=a¶m2=b. GET Parameters will be maintained.
btW: I found a solution by myself:
The shared URL is the one set in the
<link rel="canonical" href="domain.com?param1=a¶m2=b">
So if I share, the parameters are ignored if they are not found in the canonical link.
Related
HTMX is great and using AJAX for most of the stuff is awesome! But from time to time I just need a real "phyiscal" redirect to another page.
Any ideas how to achieve this without starting to write custom JS code?
Thx!
Luckily, after googleing for ages I found this post at Reddit: https://www.reddit.com/r/htmx/comments/ot6kai/comment/h6v5cn9/?utm_source=share&utm_medium=web2x&context=3
You can easily set the HX-Redirect header in your backend and on the return of the response, your browser will magically redirect.
The docs state this here but unfortunately don't explain it in more detail on other pages.
Supplemantal: I experienced an issue with JS errors occuring after the redirect - even though everything works fine.
I had a security audit on a website on which I've been working. The audit has shown that one of my parameter, called backurl, wasn't protected enough in my jsp file. This url is put inside the href of a button, button that allows the user to get back to the previous page.
So what I did was to protect it using the owasp library, with the function "forHTMLAttribute". It gives something like this:
<a class="float_left button" href="${e:forHtmlAttribute(param.backUrl)}">Retour</a>
However, a second audit showed that by replacing the value of the parameter by:
javascript:eval(document%5b%27location%27%5d%5b%27hash%27%5d.substring(1))#alert(1234)
The javascript code would be executed and the alert would show, when clicking on the button only.
They said that something that I could do was to hardcode the hostname value in front of the url, but I don't really get how this would help solve the problem. I feel like no matter what I do, solving a XSS vulnerability will just create a new one.
Could someone help me on this? To understand what's happening and where to look at least.
Thanks a lot.
As #Pointy said, the problem is more fundamental here. Accepting untrusted input and rendering that as a link verbatim (or as text), is a security issue, even if you escape the heck out of it. For example, if you allow login?msg=Password+incorrect and that's how you deal with relaying messages - you have a problem. I can make a site with: Click for cute kittens! and you see why this is a problem.
The real solution is to not accept potentially tainted information, period (nevermind escaping!), if that information ends up being rendered without the surrounding context that it is tainted. For example, take twitter. The username and the tweet are potentially tainted. This is no big deal because users of twitter get clued in due to the very design of the website that you're looking at what some rando wrote. If someone tweets 'If you transfer 5 bucks to Jack Dorsey's account at 12345678, he'll give you a twitter blue logo!', there's a reasonable expectation that it's on the users of the site to not be morons and trust it.
Your website's "click here to go to the previous page" is not like that. You can't reasonably expect the users of your site to hang over that button, check their browser's status bar, and figure it out.
Hence, the entire principle is wrong. You simply can't do it this way, period.
Your alternatives are threefold:
Instead of letting the 'previous link' property be a URL param, it needs to be in the session. Websites work with sessions, generally. You can store whatever you want in them, serverside (the HTTP handler code either manually takes e.g. the cookie and uses that to look up on-server info for that user by doing a lookup, or runs on a framework that just provides an HttpSession-style object, which works in that exact fashion).
If you really want to bend over backwards, you can include it as a signed blob. This is creative but I really wouldn't go there.
A quick hack: What if you just include Click to go back as a static link in your web page?
reply
In this code, it opens a new Gmail tab and has auto-filled to and body but the subject does not seems to be working. Can anyone tell what's the solution to this problem may be?
Not having worked with Gmail like that, a possible solution is that in the GET request the subject is the only capitalised variable, should it be a lower case like the other variable names?
I am looking for a way to fool a web page, more precisely a js module in spanking it to believe that it is on another domain name. I documented myself and I came across pkusieur forum which spoke of overwrite the variable window.location.hostname. I unfortunately did not find any answer to my question. Did I orient myself well? Can somebody solve my problem?
Thank you in advance.
EDIT
I can use explorer like firfox or chrome or use a spécifique python module for create a appilcation can do this.
You can directly change window.location.hostname, however doing so will cause the browser to actually navigate to the new URL.
You can't have window.location reflect a value that isn't the actual location of the browser.
Modifying window.location.xy results in page-reload:
console.log(window.location.hostname);
console.log(window.location.hostname="example.com");
console.log(window.location.hostname);
(In the JS console you can see that the value remains unchanged for the snippet itself, but then the page reloads from example.com)
My goal is not to redirect but I want to stay on www.example.com but the js import code is veiled www.fakeSite.com #tevemadar.
I think you would need to change origin for that, and it is the only read-only part of Location exactly for making that impossible. You want to circumvent CORS to my understanding.
I do not suggest using it, but if you desperately need some hack to test something, check https://cors-anywhere.herokuapp.com/
Trying to create a simple 'mailto' function using javascript. I just need to be able to send some links (like: See this article bla bla).
Some of the links I need to send include spaces, danish chars. So I've been using the
encodeURI() function.
The problem arises when I try to mail the link (sample code below)
var _encodedPath = encodeURI(path);
var _tempString = "mailto:someemail#somewhere.dk?subject=Shared%20from%20some%20page&body=" + _encodedPath;
If I output the _tempString to the console I get the correct encoded string. However when using the same string in 'mailto' the string loses it's encoding and returns to the way it was before.
Any clue as to why this is?
Thanks in advance :)
The link is decoded when you click it - that's normal. Since you have an http link within a mailto link, it should be encoded twice.
Email clients do their best to make things that look like links clickable. They typically decide where the link ends in a somewhat arbitrary and unpredictable manner.
In email, the best way to keep a link contiguous is to enclose it in angle-brackets like this:
<http://www.example.com/url with spaces>
But this isn't foolproof. Email is fragile and you can't control the content well enough with a mailto link. It might be better to try to reduce the complexity of the url - perhaps by providing or utilizing a url-shortener service. Any url longer than 74 or so characters is likely to be mangled by some email clients.
You should use encodeURIComponent instead of encodeURI.
More information here.
this site helped me solving any troubles with mailto links:
http://www.1ngo.de/web/formular.html
may be it's not the nicest way, but it always works with every browser i know. And it also has very cool algorithm implemented to format the content so that everything should be alright. Just try it and play around a little with code by quoting out parts of the code and you will understand very fast what exactly happens there and how to modify it for your wishes. Althoug it's a little late I hope this one helps anybody checking this question.
althoug it's in german, you just need to copy the code shown there and run it and experiment with it.