Is there anything that would cause the url rewrite module in IIS to not fire off? Maybe a site that is in integrated mode or an http handler?
I have tried a few different things to get the rewrite rules to work but nothing. My latest is as such
<rewrite>
<rewriteMaps>
</rewriteMaps>
<rules>
<rule name="rewriterule" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<action type="Redirect" url="http://www.google.com" />
</rule>
</rules>
</rewrite>
and it doesn't work at all. I've tried various regex, etc. Its like it doesnt get used.
Seems like you have your answer but here are some other possible things that might cause Rewrite Module not to work :
When you deploy your web site and see this feature not working on
your server, it is highly possible that you misconfigured something
on your server. One of the misconfiguration you might have done could
be setting the overrideModeDefault attribute to Deny for rules under
<sectionGroup name="rewrite"> inside your applicationHost.config
file.
If you are on a shared hosting environment and you see this feature
not working, then ask your provider if they have given you the
permission of configuring this part.
In your development environment, if you run your web site under
Visual Studio Development Sever, you won’t be able to see this
feature working. You need to configure your application to run under
at least IIS Express to see this feature working.
The answer in my case is that you have to be running the site in the same target platform as the url rewrite module. for example, I have x64 version of url rewrite module installed but the site was running under 32bit. Once I setup the site to run under 64bit, the rewrite started working.
Related
We have a tricky setup hosted on WP Engine which has a must-use plugin that uses Laravel.
The goal was to totally eliminate WP from the fetches that the plugin would catch and process.
On my local machine I managed to write such rule for IIS in a few minutes, but eventually needed to install Local WP to be able to come up with a rewrite rule that would work under nginx.
Here is the nginx rule that works within Local WP, that's based on the regular WP permalink rules:
location /api/v2 {
try_files $uri $uri/ /wp-content/mu-plugins/xxx/server/public/api.php$is_args$args;
}
Now, this does not work on our WPE dev site. It obviously loads the correct file, because the 404 screen I get is coming from Laravel, but it seems that everything that goes after /api/v2 got striped or not being included.
A full query would look like this:
/api/v2/admin/members?limit=10
Here's the original rewrite rule I added to IIS:
<rule name="XXX Api" stopProcessing="true">
<match url="^api/v2/(.+)/?$" ignoreCase="false" />
<action type="Rewrite" url="wp-content/mu-plugins/xxx/server/public/api.php" appendQueryString="true" />
</rule>
Can anyone please help me to figure out why the rewrite returns Not Found on WPE, but works on Local WP?
Edit:
Actually, I just dumped the request URi for this particular address.
On Local WP it's the following:
"http://xxx.local/api/v2/frontend/members"
vs. on WP Engine:
"https://xxx.wpengine.com/wp-content/mu-plugins/xxx/server/public/api.php/"
So, it doesn't seem like the rewrite works at all on WPE, it only points to the correct file.
We have our Sharepoint 2019 site set up, and everything is running fine. However, when a user clicks the Brand Bar "Sharepoint" in the top left header, it brings them to a broken page. Researched this, and it seems like this link cannot be changed in 2019, as others are having this issue.
https://social.technet.microsoft.com/Forums/en-US/1ef910ec-fb70-443e-bcf4-2d277dc11d2a/sharepoint-2019-on-premise-management-shell-not-working-as-expected?forum=SP2019
What we wanted to do is a redirect, so whenever they went to the broken link, it would just direct them to the real homepage for our sharepoint.
Example -
Broken link is http://servername/my/_layouts/15/sharepoint.aspx
Correct link is https://sharepoint.companyname.com/SitePages/Home.aspx
Here is what I came up with to add to the web.config file, but doesnt seem to be working.
<configuration>
<system.webServer>
<httpRedirect enabled="true" exactDestination="true" httpResponseStatus="Found">
<add wildcard="*_layouts/15/sharepoint.aspx" destination="https://sharepoint.companyname.com/SitePages/Home.aspx" />
</httpRedirect>
</system.webServer>
</configuration>
Any idea on what needs to be done here? Is this even possible? I didn't set up the sharepoint site here so I'm not sure how http://servername/my/_layouts/15/sharepoint.aspx even became the brand bar link.
Thank you!
If you want to redirect from servername/my/_layouts/15/sharepoint.aspx to sharepoint.companyname.com/SitePages/Home.aspx by iis url rewrite, you can try this rule.
<rule name="test6" stopProcessing="true">
<match url="^my/_layouts/15/sharepoint$" />
<action type="Redirect" url="http://sharepoint.companyname.com/SitePages/Home.aspx" />
</rule>
This has been resolved.
Not sure what happened, only thing I did was place the rule on the top most part of the tree in IIS where the server name is. Before I was putting the rule on the actual site in the drop down. I guess this makes sense since the URL I wanted to redirect had the server name in it.
Background: I'm forwarding incoming 80/443 traffic to \\SERVER2; TFS is running on \\SERVER3. I wish to route all TFS-related requests to \\SERVER3. I have to do it this way as I'm running Server Essentials on \\SERVER2, which is finicky enough to not work well under URL rewriting (almost as bad as SharePoint, but not quite).
Here's the only rule on the default website:
<rule name="TFS Rewrite" stopProcessing="true">
<match url="^tfs(.*)" />
<action type="Rewrite" url="http://server3:8080/{R:0}" />
</rule>
...and here's the Failed Request Log: https://1drv.ms/f/s!AodXF_j3BiWkhPAZwjnwC-rAecVgtw
Note the requested URL on line #87 of the PDF: http://server3:8080/tfs. I can browse to that internally just fine. The external URL is https://tfs.domain.com/tfs.
The next entry that's at all file-specific is the 404 itself, on line #165.
I just don't get this. It's a simple rule. Why would IIS turn up a 404 for a clearly valid and working URL?
EDIT
As a test, I added this condition:
<conditions>
<add input="{HTTP_HOST}" pattern="tfs.domain.com" />
</conditions>
Now if I browse to https://tfs.domain.com/, the default website loads.
This—together with the logs—would seem to indicate that while IIS is rewriting the URL, traffic isn't actually being routed to \\SERVER3.
What's going on here? This is a mystery.
OK, I got it working.
I'd installed both the URL Rewrite and ARR Modules, but I hadn't yet enabled proxy processing.
I created a dummy Reverse Proxy rule and was prompted to turn it on in IIS. I did so, deleted the dummy rule and now all is working as expected.
My home page, which is in my web root, has a relative url that starts with ../../lib/, so ../.. is above the web root.
When I try to serve my site with IIS Express, I get a 404.
How can I get this to work without moving the resources or changing the urls in the html page?
There might be a more direct way of doing this, but this is possible by adding the following to the web.config.
I noticed the 404 url was as if it was at the root, so the match url is at the root. I guess it just ignored the ../.. when interpreting the route.
First I set up a virtual directory on my local IIS to serve up the files above the root. I called it lib and pointed it at the content above the root. The actual path shown here is what I needed and just serves as an example.
<system.webServer>
<rewrite>
<rules>
<rule name="Files Above The Root" stopProcessing="true">
<match url="lib/(.*)" />
<action type="Redirect" url="http://localhost/lib/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
I'm using IIS Express just for debugging and it bears no relationship to how the site works in production. Coloring outside the lines is OK when it's just for debugging. The site build doesn't depend on this at all, and the config doesn't interfere with the site running in an actual environment because no urls are ever going to match this path.
You can enter a URL in a Crystal Reports image Graphic Location field to allow Crystal to load it dynamically at runtime. Eg: http://reports.server.com/logo.png or {?_pUrl} & "/logo.png"
Are you able to use a secure / HTTPS URL? Eg: https://reports.server.com/logo.png
I've verified outgoing HTTP connections using the TCP/IP tab of Process Explorer, but can't see any outgoing connections when using HTTPS.
My actual report is passing the base URL in via a parameter and works in an HTTP only environment. Also tried using a hard coded HTTPS url, to no avail.
I'm using version 14.0.2.364 RTM hosted in IIS on a 2012 R2 server.
Looks like Crystal Report 14.0.X (and earlier) does not support HTTPS Graphic Location - official reference from 2013.16.01.
Also checkout this thread (from 2013.Feb) where it's mentioned again Graphic Location formula over HTTPS is not supported.
Unfortunately it seems the issue is still not resolved.
The common suggested workarounds in the SAP's threads are:
using HTTP instead of HTTPS
having the image loaded locally (or from shared location)
use 3rd party tools to pre-download and store the image from the https to another (local) secure location.
It's not supported.
A SAP employee confirms this in this thread in the SAP community network (though it relates to an older version):
You're using the "Graphic Location" formula to specify a URL for the
image. When you return a string with http://, it's working, but not
with https://.
That's currently the behavior in Crystal Reports 2008 Designer, and
CR4E CRJ SDK reflects that behavior. [...] it's likely not something that would be implemented in CR4E in
the near future.
This also seems to be the case in CR2011 (14.0.x), as stated in another thread:
if the URL is secured one eg. HTTPS then crystal report wont be able
to process the images. Because HTTPS graphic location is not
supported.
A list of possible work-arounds to this problem:
Use HTTP rather than HTTPS (you may need to whitelist a particular URL or route if you require all access to be via HTTPS)
Pass the image via a binary field in your query (either by pushing it in via a dataset or by pulling it from your database)
Load images from a local filesystem
in Web.config, create a rule in the URL Rewrite, to exclude the file that generates the image, like this:
<system.webServer>
<rewrite>
<rules>
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
<add input="{REQUEST_URI}" matchType="Pattern" pattern="\bBarcode.ashx\b" ignoreCase="true" negate="true" /> <!-- Crystal não suporta imagens https.. Criando exceção para imagens de barcode, utilizadas no crystal -->
</conditions>
<action type="Redirect" redirectType="Found" url="https://{HTTP_HOST}/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>