I am sending a signup activation email containing a signup confirmation url with a confirmation token that points to an angular front end app:
...
Activate
...
Note that the token is a JWT and is fairly long.
This works find for most users, but for some clicking on the link takes them to https://domain/com only without the confirm-signup?token=...
It seems as though the mail client may be stripping off everything after the #, but I can't find any evidence of others having this problem, nor can I reproduce it.
My best guess so far is that some mail clients are seeing the # and somehow treating the trailing part as an internal anchor and stripping it...?
Has anyone else encountered this sort of problem? If so, have you found any solution short of replacing the whole mechanism with something else?
Some clients treat the hash-link just fine. Others don't. There's a conversation about Outlook being dirty about this here: Outlook strips URL hash from email
What we did to resolve this at our company is simply create a handler on our server that redirects. Your email link would become http://domain.com/email-link?url=https%3A%2F%2Fdomain.com%2F%23%2Fconfirm-signup%3Ftoken%3D1234 and your server side script would grab the query param url and immediately trigger a redirect.
You'd need to make sure that you find all links in your emails and replace them. Here's a PHP function for that, but you could do this in whatever backend language you're using. Regex here may be helpful at least.
function replaceLinks($html,$hash) {
return preg_replace_callback('/<a [^>]*href=[\"\']{1}(.+?)[\"\\\']{1}/', function($matches) use ($hash) {
return str_replace($matches[1],"http://domain.com/email-link?url=".rawurlencode($matches[1]),$matches[0]);
}, $html);
}
Yes I have encountered this issue before because of the #, I was trying to link to a anchor on a landingpage.. My solution ended up using a short.url service to "hide" the # from the html e.g. https://goo.gl/
Looks like you need percent encoding!
A lot of times when your href gets parsed (by angular in this case) it doesn't handle the special characters right, or strips them. Find your problem characters and replace them with %3F for ?, %26 for &, and %23 for #. The rest are in a chart in the link.
Once the encoded address hits the browser the url will be decoded in your url bar.
Related
I just have created primitive html page. Here it is: example
And here is its markup:
www.google.com
<br/>
http://www.google.com
As you can see it contains two links. The first one's href doesn't have 'http'-prefix and when I click this link browser redirects me to non-existing page https://fiddle.jshell.net/_display/www.google.com. The second one's href has this prefix and browser produces correct url http://www.google.com/. Is it possible to use hrefs such as www.something.com, without http(s) prefixes?
It's possible, and indeed you're doing it right now. It just doesn't do what you think it does.
Consider what the browser does when you link to this:
href="index.html"
What then would it do when you link to this?:
href="index.com"
Or this?:
href="www.html"
Or?:
href="www.index.com.html"
The browser doesn't know what you meant, it only knows what you told it. Without the prefix, it's going to follow the standard for the current HTTP address. The prefix is what tells it that it needs to start at a new root address entirely.
Note that you don't need the http: part, you can do this:
href="//www.google.com"
The browser will use whatever the current protocol is (http, https, etc.) but the // tells it that this is a new root address.
You can omit the protocol by using // in front of the path. Here is an example:
Google
By using //, you can tell the browser that this is actually a new (full) link, and not a relative one (relative to your current link).
I've created a little function in React project that could help you:
const getClickableLink = link => {
return link.startsWith("http://") || link.startsWith("https://") ?
link
: `http://${link}`;
};
And you can implement it like this:
const link = "google.com";
<a href={getClickableLink(link)}>{link}</a>
Omitting the the protocol by just using // in front of the path is a very bad idea in term of SEO.
Ok, most of the modern browsers will work fine. On the other hand, most of the robots will get in trouble scanning your site. Masjestic will not count the flow from those links. Audit tools, like SEMrush, will not be able to perform their jobs
I'm having one Rest API: /myApp/fetchData/User-Name/Password. User-Name and Password will be changed based on the request.
When i call the above restapi like this
/myApp/fetchData/srikanth/Abcdef#g123
the request is going like this:
/myApp/fetchData/srikanth/Abcdef
Basically in the URL text got removed from # character. Is there any way to solve?
Thanks,
Srikanth.
In a URI the # triggers the begins of the "fragment", and ends the path. The fragment usually specify a portion of the resource identified by the path.
When you are post-ing the request from the client, you have to escape special characters. Your request should be:
/myApp/fetchData/srikanth/Abcdef%23g123
There are different way to escaping urls, like the encodeURI or encodeURIComponent function in JS. For example, you may do:
var request = "/myApp/fetchData/srikanth/" + encodeURIComponent("Abcdef#g123");
Then the server have to decode back to the original request.
But: are you sure it is a good solution to send the password plain in that way?
I'm trying to load an external page using JSONP, but the page is an HTML page, I just want to grab the contents of it using ajax.
EDIT: The reason why I'm doing this is because I want to pass all the user information ex: headers, ip, agent, when loading the page rather than my servers.
Is this doable? Right now, I can get the page, but jsonp attempts to parse the json, returning an error: Uncaught SyntaxError: Unexpected token <
Sample code:
$.post('http://example.com',function(data){
$('.results').html(data);
},'jsonp');
I've set up a jsfiddle for people to test with:
http://jsfiddle.net/8A63A/1/
http://en.wikipedia.org/wiki/JSONP#Script_element_injection
Making a JSONP call (in other words, to employ this usage pattern),
requires a script element. Therefore, for each new JSONP request, the
browser must add (or reuse) a new element—in other words,
inject the element—into the HTML DOM, with the desired value for the
"src" attribute. This element is then evaluated, the src URL is
retrieved, and the response JSON is evaluated.
Now look at your error:
Uncaught SyntaxError: Unexpected token <
< is the first character of any html tag, probably this is the start of <DOCTYPE, in this case, which is, of course, invalid JavaScript.
And NO, you can't use JSONP for fetching html data.
I have done what you want but in my case I have control of the server side code that returns the HTML.
So, what I did was wrapped the HTML code in one of the Json properties of the returned object and used it at client side, something like:
callback({"page": "<html>...</html>"})
The Syntax error you are facing it's because the library you're using expects json but the response is HTML, just that.
I've got three words for you: Same Origin Policy
Unless the remote URL actually supports proper JSONP requests, you won't be able to do what you're trying to. And that's a good thing.
Edit: You could of course try to proxy the request through your server …
If you really just want to employ the client to snag an HTML file, I suggest using flyJSONP - which uses YQL.. or use jankyPOST which uses some sweet techniques:
jankyPOST creates a hidden iframe and stuffs it with a form (iframe[0].contentWindow.document.body.form.name).
Then it uses HTML5 (watch legacy browsers!) webMessaging API to post to the other iframe and sets iframe's form elements' vals to what u specified.
Submits form to remote server...done.
Or you could just use PHP curl, parse it, echo it, so on.
IDK if what exactly ur using it for but I hope this helps.
ALSO...
I'm pretty sure you can JSONP anything that is an output from server code. I did this with ClientLogin by just JSONPing their keyGen page and successfully consoleLogged the text even though it was b/w tags. I had some other errors on that but point is that I scraped that output.
Currently, I'm trying to do what you are so I'll post back if successful.
I don't think this is possible. JSONP requires that the response is rendered properly.
If you want another solution, what about loading the url in an iframe and trying to talk through the iframe. I'm not 100% positive it will work, but it's worth a shot.
First, call the AJAX URL manually and see of the resulting HTML makes sense.
Second, you need to close your DIV in your fiddle example.
I am building in invite/registration form for my site. The idea is that one user invites another user, which sends a code with a url to register with. The problem is that the code can have an encoded backslash in it. When that encoded backslash is processed in Angular, it seems to get decoded and ends up busting the routing.
http://localhost:54464/ang/register/owi0%2fCQCrjzBcwqEORVVHhrICIANGKxtxMJ2Kh91y%2bNhhB%2br06appZzEVPhpkP2C
becomes:
http://localhost:54464/ang/register/owi0/CQCrjzBcwqEORVVHhrICIANGKxtxMJ2Kh91y+NhhB+r06appZzEVPhpkP2C
How can I stop this behavior?
Try using a route like:
/register/*code
The code will contain the string with the slashes
source
It is typically used for path-like url arguments...but I don't see why this wouldn't work for your case.
I'm running an app with Sinatra/backbone.
Let's say I visit the page http://localhost:3000/cases/1/read?name=Some%20Guy that is using the name parameter to display data on the page.
Does this present an XSS issue?
I'm just trying to send data from one page to another through a button click with the param data.
A quick test is to try the URL
http://localhost:3000/cases/1/read?name=<script>alert('foo');</script>
If the script executes and an alert popup appears, then XSS is definitely possible.
Other XSS patterns are possible too depending on where the name value is output.
You should output encode to prevent this type of attack. The encoding to use depends on the language context of your output (if is it JavaScript, HTML, or CSS, etc). e.g. " becomes " in HTML, but \x22 in JavaScript and JSON. The correct encoding prevents an attacker being able to escape out of the context and inject their own scripts. You should also set the charset to UTF-8 to prevent some UTF-7 filter evasion attacks.
Not necessary. All dependence on which way data shows to user. If you keep in mind, that data can be wrong and for example escape string before output - it will be ok.