Hi,
I see that the direct links generated have a lot of strange symbols
https://XXX.quickfile.co.uk/?d=QH%2FXj%2FfdSHYaB%2FburI8w%3D%3D
Like %3d and %2f
This does not generate a nice url at all and maybe (not sure) can give problems when shared on different tools, email or others.
Would be possible to remove the symbols from the link generator in the future?
Thanks
Hi @expertoswp
The symbols form part of the encryption used in the link to ensure they are not easy to guess, which in turn helps prevent unauthorised access to invoices themselves. This is an important feature as often the link will automatically log the user in and give them access to the invoices, statements and estimates on their account.
This isn’t something we’re going to be able to change I’m afraid.
Well, I have seen this done on several sites without the need to use Ascii symbols.
I am not suggesting to remove the symbols, but to make the user friendly.
I suppose I will use a shorturl system, but that will make me go through more steps to manage my account here.
If a shorturl system can do it, you could too.
Also, any link that can be send by email, it is not secure, no matter how difficult to guess it is.
As soon as you make easy to copy and paste, it is not secure anymore.
If you want to make them secure, put a timer on them so the links only work for 24 hours or something like that.
What I am trying to say is that security is not one of the features of those links at all, so justify the symbols to make them secure does not make sense at all either.
Those links are designed to be shared, not to be secure. Make them easier to share.
May I ask why your client is hand typing the links? That’s probably the bigger question here.
The % symbols are the result of URL encoding:
QH%2FXj%2FfdSHYaB%2FburI8w%3D%3D
Decodes to…
QH/Xj/fdSHYaB/burI8w==
We don’t roll our own encryption, instead we use an established encryption algorithm that is widely adopted and tested across the web. I’m not aware of a specific encryption method that does not use symbols, although any method that uses a smaller character space is going to be inherently less secure.
But again, these links were never intended to be hand typed so it shouldn’t really be an issue.
This is already possible, you can enforce a rule that will require your client to enter their password before viewing the invoice. This setting can be found in the client settings screen.
Hi,
No, they do not hand type the links, but the longer the link and the more strange symbols on it, more difficult to anyone to click on them.
I am trying to sell something and the estimate link is not helping, that is the main reason to ask for that improvement. 
Create a link without unsafe characters and without ones that require encoding is not a bad practice and it does not affect the security of the link, but can help to use those links and improve the opening and the approvals of the estimates.
https://perishablepress.com/stop-using-unsafe-characters-in-urls/
Safe characters Alphanumerics [0-9a-zA-Z], special characters $-_.+!*’(), and reserved characters used for their reserved purposes (e.g., question mark used to denote a query string)
If you limit the characters to safe ones the links will be exactly as secured as they are now, but they will be easier to use, to copy, to share, etc.
It should be a not that difficult thing to change, and it will help a lot to make those estimate links more useful.
Thanks!
Just to confirm, that when you send an email to your client through QuickFile for an estimate or invoice, we don’t directly show the link, it shows "Click here to view your invoice" (or estimate).
For the vast majority of email clients, this will show as the text rather than the link.
If you have a Power User Subscription, you can go to Account Settings >> All Settings >> Sent Email Log to view the emails sent to your clients.
Hi, Thank you for the suggestions but it does not work for me (maybe for others but I do not recommend that)
I cannot send the emails from your platform because I cannot use the same email for all the trading styles.
I customise the email for each client, the estimate approval is one of the important process on my business, so I prefer to manually do those emails.
Also I do not send html emails most of the time, as I do not trust that my clients will see the same things I do, so most of the times, for invoicing and estimates, I use plain text emails, and I do not encapsulate the links below other words.
So I copy and paste the link directly on my emails.
Therefore I would like to have nicer urls without encoding, if that is possible.
If not, I will try to use a shorter url but I prefer to keep the process with only one tool.
Thanks!
The point of having special characters and longer strings is to mitigate against brute-force attacks. There’s no encryption mechanism I am aware of that will only use alpha-numerics.
The other option is a URL shortener like https://bitly.com, however these are known to be insecure and not recommended for private correspondence.
https://www.schneier.com/blog/archives/2016/04/security_risks_11.html
Hi Glenn, I am not sure you read all I wrote, as you are recommending the same thing I suggested.
Let me repeat it again:
Encoding a URL is not an encryption mechanism at all.
I am not saying use only alfanumerics, but use the proper URL safe characters so the links do not need to be encoded (so they look nice).
I will be the same but instead of using all symbols, limit them to the safe characters.
"Safe characters Alphanumerics [0-9a-zA-Z], special characters $-_.+!’(), and reserved characters used for their reserved purposes (e.g., question mark used to denote a query string)"
You can have an url like this
asdew(o)23!0j_daj-i+dew.qpj03ieqw
And that will always show nice on the URL browser.
I do not think is a big change to do, it will be the same feature but much better implemented.
Thank you for considering it.
After reading your link, I would like to give you my clients point of view.
For them, receiving a link from me with a quickfile.co.uk extension is like I am using a shorturl system, because they do not now your domain at all.
So everything that applies to the link you pasted, is what they are going to follow. First rule: Do not use them and do not open them.
If the link comes also with this like QH%2FXj%2FfdSHYaB%2FburI8w%3D%3D
instead of
QH*Xj(fdSHYa8_burI8w–
It will raise more problemas as my clients are not that technical at all, so they can be frightened with small things like this.
That is the only thing I am asking, to use symbols that do not need to be encoded, so the links looks better.
If you think is not necessary after all the reasons I have given, it is ok, I will try an alternative for sending my proposals and get an approval, but It was nice to have everything on the same place.
Thanks again for taking time to answer me.
We can encode what we already have but this will result in much longer links (maybe that’s an acceptable trade off?), e.g. with Hex Encoding…
QH/Xj/fdSHYaB/burI8w==
becomes
51482F586A2F666453485961422F6275724938773D3D
To be honest I’ve not heard any other similar requests along these lines, but I’m happy to update this to a feature request for now.
The problem we have is adding a different encode / decode method that will break all existing links in issue or alternatively forking the code to provide two different entry points. It’s certainly doable but I would rather see more consensus for this first.
Sorry, I think I am not explaining the request well enough.
Let me try again.
If you use this symbols:
Alphanumerics [0-9a-zA-Z], special characters $-_.+!’()
And not the ones you are using now:
/ =
You do not need to URL encode them at all.
I am not suggesting to use another encoder, just not to encode them as this is not necessary and do not create any advantage but some disadvantages to their use.
It wouldn’t be that much longer - I get 407fd78ff7dd48761a07f6eeac8f30 as the hex-encoded equivalent of that base64 data, or there are modified base64 encodings that use _ and - instead of / and + which then don’t need percent-encoding.
More info on the topic:
Which Characters Are Allowed in a URL?
The characters allowed in a URI are either reserved or unreserved (or a percent character as part of a percent-encoding). Reserved characters are those characters that sometimes have special meaning, while unreserved characters have no such meaning. Using percent-encoding, characters which otherwise would not be allowed are represented using allowed characters. The sets of reserved and unreserved characters and the circumstances under which certain reserved characters have special meaning have changed slightly with each revision of specifications that govern URIs and URI schemes.
According to RFC 3986, the characters in a URL have to be taken from a defined set of unreserved and reserved ASCII characters. Any other characters are not allowed in a URL.
The unreserved characters can be encoded, but should not be encoded. The unreserved characters are:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~
The reserved characters have to be encoded only under certain circumstances. The reserved characters are:
! * ’ ( ) ; : @ & = + $ , / ? % # [ ]
From https://www.url-encode-decode.com/
https://en.wikipedia.org/wiki/Percent-encoding
@expertoswp - As my colleague @Glenn explained above, we can certainly look into changing this, but given the effect it would have on the existing links, we would need to see additional support for this.
Thank you for your suggestion. We’ll leave this topic open and will monitor interest from other users who add their comments going forward.
Thank you.
If you change the part of code that generate the URL, and limit the characters to the ones that does no need to be encoded on a URL (see list on my latest post) it won´t affect at all to past users, but the new links generated will be using the recommended characters for URLs without any encode.
Doing it this way, old links should work, and new links will use the new format.
We use an encryption method that outputs these characters. If we want to get rid of them we either need to use a different method of encryption or run the output from the encryption through hex encoding (to convert to a longer alpha numeric string) or something similar, which is what I suggested earlier.
Writing our own encryption is a bad idea, and even changing to another algorithm that outputs alpha-numeric with no extra encoding needed (if such a method exists) still requires careful consideration.
Thank you @Glenn
I can see that you have a more complicated implementation of what, in my mind, was a much easier redirection.
But of course I do not know the project and I am sure there are reasons for that.
So, it doesn´t matter the reason, the reality is that my request is much more complicated to achieve with the actual development.
Thank you for taking time to explain it.
I will use a shorten url on top of this to improve the links.
Hope you can leave this on the “future nice upgrades to have” list. 
Thank you again for your time and for the great support.
This topic was automatically closed after 7 days. New replies are no longer allowed.