I want to redirect to a page that and force https:
e.g
Response.Redirect("~/Login.aspx");
I want to redirect to
https://myserver/Login.aspx
how can i force https?
Thanks Silky for starting me off.
I've ended up with
var url = String.Format("https://{0}{1}",
Request.ServerVariables["HTTP_HOST"] ,
ResolveUrl("~/Login.aspx"));
Response.Redirect(url);
I like to call this method from Page_Load in any page where I want to force https. Specifically, from any page where the user may enter a password, such as login, registration, and password reset pages.
protected void ForceHTTPS()
{
string serverName = Request.ServerVariables["SERVER_NAME"];
string pagePath = Page.AppRelativeVirtualPath.Replace("~", "");
string queryString = Request.Url.Query;
if (serverName != "localhost" && !Request.IsSecureConnection)
{
Response.Redirect("https://" + SECURE_DOMAIN + pagePath + queryString);
}
}
The reason I use a pre-defined constant for SECURE_DOMAIN rather than just reading it out of the Request.ServerVariables["SERVER_NAME"] is that our SSL certificate only works if there is a "www." on the beginning of the domain name, so I want to make sure to force that domain name too in case the user has browsed to the site using the domain name without the www., or potentially used some other domain name alias.
And I do not do the redirect if the server name is "localhost" so that the code also works in my development environment when run from Visual Studio.
Related
So basically I want to redirect the website.com/blog to website.com/blogs. When I did the redirecting on localhost it's working fine but when I push it to the staging level for validation it throws the error "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
if (currentHost.Host.StartsWith("www."))
{
context.HttpContext.Response.Redirect("https://website.com"+path);
context.Result = RuleResult.EndResponse;
}
var url = context.HttpContext.Request.Path.Value.ToLower();
if (url.EndsWith("/blog"))
{
context.HttpContext.Response.Redirect("/blogs");
context.Result = RuleResult.EndResponse;
return;
}
This is the condition that I'm using
Need to redirect website.com/blog page to website.com/blogs ,with above mention logic it works fine on localhost but not on staging and website is hosted on azure
I got this code from here.
Notice I remmed out the part that redirects to ISSExpress 44300 port because I want to use II7.5 on dev box without https.
public class CustomRequireHttpsFilter : RequireHttpsAttribute
{
protected override void HandleNonHttpsRequest(AuthorizationContext filterContext)
{
// The base only redirects GET, but we added HEAD as well. This avoids exceptions for bots crawling using HEAD.
// The other requests will throw an exception to ensure the correct verbs are used.
// We fall back to the base method as the mvc exceptions are marked as internal.
if (!String.Equals(filterContext.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase)
&& !String.Equals(filterContext.HttpContext.Request.HttpMethod, "HEAD", StringComparison.OrdinalIgnoreCase))
{
base.HandleNonHttpsRequest(filterContext);
}
// Redirect to HTTPS version of page
// We updated this to redirect using 301 (permanent) instead of 302 (temporary).
string url = "https://" + filterContext.HttpContext.Request.Url.Host + filterContext.HttpContext.Request.RawUrl;
//if (string.Equals(filterContext.HttpContext.Request.Url.Host, "localhost", StringComparison.OrdinalIgnoreCase))
// {
// // For localhost requests, default to IISExpress https default port (44300)
// url = "https://" + filterContext.HttpContext.Request.Url.Host + ":44300" + filterContext.HttpContext.Request.RawUrl;
// }
filterContext.Result = new RedirectResult(url, true);
}
}
Then, in my FilterDonfig.cs I added this. What it does is it only uses the override above if Web.config has "Debug=false", which is what it has in Production. I don't need to run Release in my development environment, and I also don't want configure local IIS to handle SSL. Notice I remmed out the "RequireHttpsAttribute()" and used the new one above.
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
if (!HttpContext.Current.IsDebuggingEnabled)
{
/////filters.Add(new RequireHttpsAttribute());
filters.Add(new CustomRequireHttpsFilter());
}
}
}
Am I doing the right thing? Is this how to make sure SEO is optimized because search bots only keep track of one website? My understanding is that "http" and "https" are considered 2 separate websites by search engines. Am I doing this in the right place? Not sure what other code I am getting in the way of.
===============
I asked my ISP about how to do permanent redirects and suggested this solution and they said:
Dear Customer,
We did not setup redirection. However, we corrected https bind setting in IIS to fix the problem.
I wonder if IIS can do the same thing and that is what they did. I hope I'm in the right forum :)
How about doing this at an IIS level using the URL rewrite module: http://forums.iis.net/t/1153050.aspx?URL+Rewrite+for+SSL+redirection
To turn it off in dev, just set the enabled rule to false in your dev web.config, but enable it for all servers/environments that have HTTPS set up.
I've used it in the past and its worked really well. Saves cluttering your app with code that isn't app related.
I want to change the reset-password email template url
I want to change
localhost:3000/reset-password/dP8cuMPE220mEPA7l0uSRIq4
to
app.mysite.com/reset-password/dP8cuMPE220mEPA7l0uSRIq4
I've done this
Accounts.emailTemplates.resetPassword.text = function(user, url) {
url = url.replace('#/', '');
url = url.replace('localhost:3000', 'app.mysite.com');
return "Click this link to reset your password: " + url;
};
This works on my localenvironment but when in production it doesn't have localhost:3000
so the url will not change
I want to change the host, how to do this?
You need to set the ROOT_URL environment parameter. Meteor will use it to generate this link. So if you set ROOT_URL="http://app.myside.com/, then the generated url will be http://app.mysite.com/reset-password/blahBLAH.
Before asking this questions I have carefully assessed the feasibility to solve the following problem.
I have an external link being fired from an email viewRequest.xhtml?requestID=6. I use a filter to intercept the incoming request and in case the user is not authenticated it is forwarded to the login.xhtml page. After the user is authenticated the request is forwarded by FacesContext.getCurrentInstane().getExternalContext().redirect(redirected-url) Then it displays the page successfully.
Now if try to logout from same page i.e, viewRequest.xhtml page, the requested URI is viewRequest.xhtml again which takes me to the same page instead of logging out and redirect me to the login page.
I have the real concern of why the request.getRequestedURI in filter is still viewRequest.xhtml instead of login.xhtml
Code for reference
AuthenticationFilter - User is un-authenticated - Adding requested email link in session
String from = req.getRequestURI();
if (req.getQueryString() != null) from += "?" + req.getQueryString();
req.getSession().setAttribute("from", from);
res.sendRedirect(req.getContextPath() + "/faces/pages/login.xhtml");
After user is logged in
if (from != null && !from.isEmpty()) {
externalContext.getSessionMap().remove("from");
externalContext.redirect(from); *-----------Original URL re-direction---------*
return null;
}
else{
result = "adminHome";
}
Now we are in viewRequest.xhtml page - loaded successfully - Now clicked on Log out
String from = req.getRequestURI(); <!--FILTER-->
The value of requestedURI is still viewRequest.xhtml
logout() in LoginController.java
FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
return login;
Please help. Thank you very much.
I'm confused about the behavior of RedirectResult - in some cases (with https), the redirect doesn't seem to happen, but something more like a transfer.
If a user tries to access an internal page without being logged in, they are directed to the login page. After logging in, they're directed back to my app, with query string parameter
schema://host:port/myApp?returnUrl=Inspections.mvc/Edit/43523
The code in the HomeController that handles this looks for the redirectUrl, and does this:
if (returnUrl != null)
{
return Redirect(returnUrl);
}
In my dev environment and one QA environment, I see that a redirect response goes back to the browser, which makes another request, as expected.
But in production and another QA environment (both of which use https), the last redirect doesn't happen. The browser continues to show the url
schema://host:port/myApp?returnUrl=Inspections.mvc/Edit/43523
and displays the content that would be returned by the page Inspections.mvc/Edit/43523.
I'm perplexed - is this expected behavior when RedirectResult is used? Is https the relevant difference?
EDIT: Checking traffic, I see that in the environments using https there IS a redirect (301- moved permanently), but it is back to exactly the same address:
schema://host:port/myApp?returnUrl=Inspections.mvc/Edit/43523
This additional information leaves the mystery as puzzling as ever.
Looking at the source code of RedirectResult class you can see that it should do either a 302 or 301 depending on the kind of redirect you want:
public override void ExecuteResult(ControllerContext context)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (context.IsChildAction)
{
throw new InvalidOperationException(MvcResources.RedirectAction_CannotRedirectInChildAction);
}
string destinationUrl = UrlHelper.GenerateContentUrl(Url, context.HttpContext);
context.Controller.TempData.Keep();
if (Permanent)
{
context.HttpContext.Response.RedirectPermanent(destinationUrl, endResponse: false);
}
else
{
context.HttpContext.Response.Redirect(destinationUrl, endResponse: false);
}
}
It should be working as expected no matter what schema you are using. Did you look at the actual request/response with a http sniffer such as Fiddler?
Maybe your browser is choosing not to update the URL for some reason and the problem is not in the actual redirect/rewrite.