We have a asp.net web application will send a confirmation email with redirection url to users email once they confirm the registration. But while sending the url, the url "https://exchcas/owa/redir.aspx?C=cUl43mOPekKnIMaLWRr1yZSp78A6N9EIC9oVlRLrzMFpuM-1UucMKAHOqY5VYM297Nr6m36XwhM.&URL=" will be appended to our url.
for example,
our redirection url is http://localhost:63554/Reg.aspx
the url will be send some thing like below,
https://exchcas/owa/redir.aspx?C=cUl43mOPekKnIMaLWRr1yZSp78A6N9EIC9oVlRLrzMFpuM-1UucMKAHOqY5VYM297Nr6m36XwhM.&URL=http://localhost:63554/Reg.aspx.
Can anyone pls let me know why this append happening? and what is the meaning of this appened url?
This is a standard Exchange behavior for security reasons. Available in Exchange 2003/2010 (not sure about 2013). In OWA email is located at .../username/inbox/message.eml. If user clicks on direct url such as http://localhost:63554/Reg.aspx then on that link you could read HTTP_REFERER value and obtain "/username/inbox/message.eml". So, the purpose of having redir.aspx is to avoid sharing a username and email subject as a part of HTTP_REFERER.
Read more here http://blogs.technet.com/b/exchange/archive/2004/07/26/197289.aspx
You can also take a look here http://blog.leederbyshire.com/2013/03/28/how-to-make-your-outlook-web-app-2010-redir-aspx-a-little-safer/
I wrote a skip-owa-redir userscript that replaces each indirect redir.aspx link with a direct link to the target URL, using rel="noreferrer" to address the privacy concern.
Related
I have created a post on my websites when I shared on LinkedIn, it's not showing complete URL of sharing.
Currently, I am using https://www.linkedin.com/sharing/share-offsite/?url=www.example.com/share/?id=12654
But When I am sharing with LinkedIn using above its redirect to below URL :
www.example.com/share
Its removing parameter which passed using id. How I can get the full URL: www.example.com/share/?id=12654
Don't forget to do URL-encoding with parameters you are feeding to another URL. So, your link should be ...&url=https%3A%2F%2Fw..., and not ...&url=https://. Your URL also contains a question mark that should be escaped. Ultimately, your URL should look like this..
https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.example.com/share/%3Fid=12654
URL encoding is required any time you are sending a URL as an argument to the GET param of another URL.
In case you want to know more: Official LinkedIn Share Documentation
If you are interested in a regularly maintained GitHub project that keeps track of this so you don't have to, check it out! Social Share URLs
Im currently connecting with a site which uses basic auth, and my url looks like http://username:password#mysite.com. It works, but everyone can see the password; Is there any method to hide it, by means of base64 or something similar?
This syntax is just a shortcut for the browser. Some browser will use this syntax to build the Authorization headers (some will not).
But. One thing is sure. You are giving the user+password to everyone. If your site use basic authentication, then you need to give the user and password information to your users, like in an email for example. Why would you add an authentication and then let everybody access the authenticated section?
HTTP Basic authentication is not very secure. But can be used to prevent indexation by bots, or with https. When you add this sort of (annoying) popup the users will have to enter the credentials, there is no other way. And the browser will record the credentials and add the same information (user+pass encoded in base64 -- which means is in clear text, no security--) for each page requested on your site until the browser is closed. So you do not need to add the credentials on the url, the browser will do it for you, after a first popup.
Currently my client have 2 websites, for example: abc.com and us.abc.com. They want that everytime an user from US access abc.com, he/she will be redirected to us.abc.com. That can be solved very easy, however after solved that issue, I have ran into another issue related to Facebook.
That's when an user browse abc.com and they click share facebook button somewhere in the website, what was shared is always what appear in the home page of us.abc.com.
What I think is that because Facebook server is in US, so when facebook made the request, it was redirected to us.abc.com => Cause the issue.
Are there anyway to white list facebook request and skip it from the redirect rule ?
Yes, you can detect that Facebook is making a request. You can do this by using the request headers, as explained in the question How to recognize Facebook User-Agent
.
Based on those user-agent strings, you can decide wether to redirect.
I am interested to detect the email client or website a new user of my site is redirected from. For instance, if he was redirected from Gmail.com (by clicking a link in one of his email there) I would like to track that.
If I need to manipulate the links leading to my website somehow I can do that.
I know there is a way to do that cause I have seen many sites and services doing it but I would like to find out how. I can track the user agent but this tells me nothing about the site or email client.
You must use QueryStrings for this purpose. For example the link that sends the user to your site must be like this www.yourwebsite.com/default.aspx?sender="googleMail"
You can get this using the code shown below when your default.aspx page loads
if(Request.QueryString["sender"]!=null)
{
string Sender=Request.QueryString["sender"].ToString();
}
You can set different Querystrings like
www.yourwebsite.com/default.aspx?sender="googleMail"
www.yourwebsite.com/default.aspx?sender="YahooMail"
www.yourwebsite.com/default.aspx?sender="googleAdsense"
There are methods to trace the users Browser, IP address etc. But to trace this you must adopt the above method.
For a web app I want to let users review and edit a record they made previously through a browser form. In their confirmation mail, they get an access link with a secret token, like http://myapp.com/edityourstuff/hdD8sF2m Clicking this link shows them a form in which they can edit the existing data they submitted earlier.
This is not as secure as a username/password combination, but much more convenient and suitable for my situation.
However, I want to make this as secure as possible.
GET URLs
If the link containing the secret access token is disclosed, unauthorised people can access the data. My concern here is about shared/public computers.
I was planning to tackle this problem with the following pattern:
Access to /edityourstuff/ds8sdfhe via link in email
Start a session, store the secret token in there
redirect to clean /edityourstuff without token
The app now has access to the token in the session and can display the form accordingly. And the URL bar does not show it.
My question now is: Do browsers store the initial URL, that immediately redirects to the clean URL in their history?
I know that the different HTTP redirect status codes (301, 302, 303) have different use cases in theory. Is there any information on how different browsers treat the different redirect codes in respect to (not) storing the initial URL in browser history?
I just did some quick testing myself, with Firefox 7.0.1
When using the above pattern, no matter if 301, 302 or 303 redirect, Firefox does not return to the initial URL when clicking the back button. However, it is shown in the full browsing history and is part of the URL completion list of the browser bar.
This is exactly the drawback I was hoping to avoid.