I have a php script that run perfectly when requested by the browser (example):
http://www.kwiksher.com/k3Serial.php?key="XXXXX"
in this case, I get the information of an user with the key XXXXX, which is the expected behavior.
However, inside my Photoshop plugin, I must to call it via socket, having to force a port in the connection:
http://www.kwiksher.com:80/k3Serial.php?key="XXXXX"
Doing that, I get the the content of Azure default 404 page (it is not even my customized 404 page).
If I use the same call (with the port added to the domain) on a browser, it works fine as well.
Any idea on how to fix it? I tried to flushDNS on my machine as well without success.
Thanks a lot,
Alex
It's likely that the socket library won't be using HTTP and therefore isn't sending a host header and the web tier on Azure can't actually figure out which Website it should serve the content from.
As you using this with a plug-in perhaps try and use the default hostname issued by Azure instead of a custom domain.
Related
I am trying to develop a PowerShell tool to gather "Discovery" information about devices on our network. We already have a commercial discovery tool but in quite a lot of cases, it is not giving us very much information.
The idea is to probe a subnet for devices (typically appliances) that have Web-based management interfaces. Our theory is that in many cases the home page content will allow us to detect what sort of device it is (containing manufacturer name, device model name etc). Obviously, such info will need to be extracted by parsing the body of the page. So, the script I have written first uses Test-NetConnection to do a port 80 test and a port 443 test. If the device is listening on port 80 or 443 the script will then use Invoke-WebRequest to grab the contents of the page.
I have used some code from here Ignore SSL warning with powershell downloadstring to disable certificate warnings as a lot of these devices will have self-signed untrusted certificates. That all works OK. The problem that I am having is that some of the devices I am testing on will display a page in a browser but using PowerShell's Invoke-WebRequest raises an error. After some investigation, this is because the Webserver of the device returns a non 200 status code. An example of this is setting up Apache on a Linux Box and enabling https with a self-signed certificate. Accessing the page using MS Edge displays the "Testing 123" page with a not secure warning on the address bar. However, accessing the same page via Invoke-WebRequest throws an exception. In this particular case it is because Apache returns a 403 Forbidden error. This is by design for Apache straight out of the box with the "Require all denied" setting in the httpd.conf file. Of course, the exception can be caught (which I have done) but the web page content is not available in this case within PowerShell even though it is displayed in a browser.
My next thoughts were that the Web server is behaving differently because it knows the PowerShell script is not one of the common browsers. So, I tried to use the -UserAgent parameter to Invoke-WebRequest to fooling the server into behaving the same way as it does with the browser and returning the content. However, this does not achieve what I am looking for.
The 403 return is just one example. It seems Appliances with a home page that require credentials (most/all? of them) returns a 401 error and again the page content is not available within PowerShell.
Does anyone have any pointers as to how I can make this work?
I am trying to point the domain www.xxx.com to www.ttio.com/tc using cloudflare to enable to the https on the site.
On GoDaddy I have changed the nameservers to cloudflare's recommended name servers
I have also gone to "Page rules" on Cloudflare and added a forwarding rule so that the above is in place.
On going to www.xxx.com however, i get the following error:
It redirects to this url: https://shortener.secureserver.net/error_404
and the error is:
Destination
Unknown
Everything's working on our side, so the link you clicked is either wrong or has been retired.
I have done everything I think I should have, so could anyone shed any light on this please?
You can't point a domain (e.g. www.xxx.com) at an URL (e.g. www.ttio.com/tc). A domain needs to be converted to an IP address by the browser.
If the web server for www.ttio.com is set to recognise www.xxx.com and serve the content from the /tc folder under www.ttio.com, just set up a CNAME for www.xxx.com pointing www.ttio.com and it will work.
If the web server for www.ttio.com doesn't know about www.xxx.com at all, you'll need to use a translation proxy. One way of doing that is using a Cloudflare worker to map the www.xxx.com/PATH URL to www.ttio.com/tc/PATH. An example of how to do this is at https://developers.cloudflare.com/workers/tutorials/configure-your-cdn/. You may also need to rewrite the HTML so that links in the pages don't point to www.ttio.com/tc. An example of how to do that is at https://developers.cloudflare.com/workers/reference/apis/html-rewriter/.
I am developing a web service using REST API. This REST API is running on port 6443 for HTTPS. Client is going to be a Single page application running on port 443 for HTTPS on same machine. The problem I am facing is:
While I hit the url say: https://mymachine.com/new_ui I get certificate exception for an invalid certificate because I use a self signed one, so mymachine.com:443 gets added to server exception. But still requests doen't go to REST API as they are running on https://mymachine.com:6443/restservice. If I manually add mymachine.com:6443 to server exception on firefox it works but it will not be the case in production for customers.
Some options that I thought are:
1. Give another pop up and ask to add REST server on port 6443 exception too.But this doesn't look proper as why an end user should accept the cerf for same domain twice. Also REST api server port can change.
Can we programmatically add exception for domain and both the ports in one shot? Ofcourse with the consent of the user. 3. Use a reverse proxy. But then its going to have memory footprint on our system. Also it will be time consuming.
Please suggest some options. How do I deal with it. Thank you
We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>
I have an issue with appears to occur randomly (however i suspect it occurs when starting up the application or changing the application settings). The error I'm getting is as follows:
An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80
The particular error in my case occurs when trying to generate a authentication token using Identity Framework by making requests to the following url:
https://domainname/api/token
Note that the api/token url is specified within the owin pipeline > OAuthAuthorizationServerOptions > TokenEndpointPath. This get set on startup of the application.
From my understanding 127.0.0.1:80 is azures localhost and is forbidden for us to access, i'm not sure why its defaulting to localhost as a domain, my educated guess is something is happening during the startup that's first setting the host to localhost.
My question is does anyone else get this on startup (while the site is warming up) for azure web apps?
Have i configured something incorrectly for me to be getting this behavior?
I know this is a little open ended but is there anything i can do to resolve this issue?
That is the well-known issue described in the official documentation. You may not to access not just a 127.0.0.1, but i suspect that the problem is even a little different - it looks like something is wrong with the :80 port usage. IIS use that port, and i would try to change the port used by your app.
However, from your description is not clear who is that guy who tries to do that - your app tries to do something with the 80 port, or the Azure WebApp functionality.
Please try to start from the eliminating the possibility of some renewing events by enabling Always On in the Azure Web App setting. It will make your web app always on, and will help to understand if that is caused by the service.