I have a url which is not working when i tried hitting it directly, but it works when I append /# to the url.
But for QA when I hit the url it is working where it automatically adding the /# and goes to required login page. In QA it was manually deployed not through VSTS pipeline
Actual url(not Working): https://<applicationurl>.azurewebsites.net
URL(working one): https://<applicationurl>.azurewebsites.net/#
Deployment: VSTS build and release
Hosting: Azure App Service
Application: Java, Angular6
In Java a URI of the form "http://x.y.z" has a null path.
A URI of the form "http://x.y.z/" has an absolute path which is "/".
Some browsers will automatically correct an URL by appending "/" if the URL does not have a path, but programmatic interfaces and servers may not.
I suspect that what you describe is just a user error - you need to make sure the input URL has a path. This is what happens when you append "/#" - but I don't think the # makes any difference (that's just adding an empty fragment).
Related
Organizations registering on my application can provide their external websites url for their profile page. The resulting html when displaying the link to their site is example.com (Confirmed by inspecting the page in chrome). When hovering over the link or actually clicking it. The url is apparently interpreted as relative and https://localhost:8443/MyWebApp/profile/ is prepended to it.
Do I have to check and possibly modify links that users input or is there likely something in my configuration that is causing this behavior?
EDIT: Is there a simple method of countering this? Such as a jsp tag or using a url rewriter? (Tuckey)
This is the expected behaviour. Since the provided URL does not begin with a protocol (http, https, ftp, whatever) it is considered relative, and since it does not start with a /, it is considered relative to the current URL.
I have developed an application which contacts a Sun One web server. The Web Server has Lotus domino and SiteMinder Plugin.
Below is the URL for the application
http://HostName.example.com
After hitting the URL in the browser, the URL is redirect to webserver and a login page appears with below URL.
http://HostName.example.com:9898/SiteMinderagent/forms/login.fcc?TYPE=
33554433&REALMOID=06-1716e557-15f3-100f-b9a4-835cc8200cb3&GUID=&SMAUTHREASON=
0&METHOD=GET&SMAGENTNAME=$SM$sHjbzl4f9R%2bcSa0%2fEgnu6oUQQPMQnUgkU6Zvx5zWZpQ%
3d&TARGET=$SM$http%3a%2f%2fshivalik%2ered%2eiplanet%2ecom%3a9898%2fvalidation%
2findex%2ehtml
After logging into the application, the request is redirect using the TARGET parameter( URL is decoded in the application) from the URL Now the login doesnot work if i block the HTTP requests. As the TARGET parameter is a HTTP request, I am unable to login into the application.
Is there any way I can change the TARGET parameter to HTTPS. Can i know in which file I can change it in the WebServer. The Sun One Web Server runs Solaris OS. I have tried hard finding the solution as I think the URL is appended with Query strings like SMAGENTNAME, SMAUTHREASON, TARGET in the Servlet of the Domino.
The TARGET parameter is populated with the URL originally presented by the user - i.e. in your example http://HostName.example.com will result in the TARGET query string parameter containing the same URL plus the other parameters generated by the SiteMinder agent.
Possible solutions in your case could be to hardcode the TARGET by putting something like the following on the top of login.fcc:
#TARGET=https://hostname.example.com/
That would cause the FCC to ignore the query string parameter that is POSTed and instead will hardcode it.
Alternatively if you need to preserve the path component of the URL (e.g. http://hostname.example.com/path/to/file.html) you could add some javascript to the FCC page. The standard implementation populates TARGET into an element so you could use JavaScript to parse the value and replace http:// with https:// if required. Make sure that your Agent Configuration has single and double quotes in BadFormChars (BadFormChars=%22,%27) to prevent XSS attacks.
There is also an Agent Config parameter HttpsPort that you can use to "trick" SiteMinder into thinking you're serving HTTPS traffic out of port 80 but you will have to test for any unintended side effects.
PHP doesn't get parsed when I try to run the PHP page. I am using NetBeans and running Apache Tomcat as the server. I have defined the interpreter for PHP which is shown in the following snapshot:
If I try to run the PHP page from within the IDE (by using the default shift+F6), it runs, but with a URL file:///C:/Users/user/AppData/Local/Temp/php_1.php11992.html for a file named php_1.php. But when I try to test the URL localhost:8081/app/php_1.php, the PHP in the page isn't parsed, and I see only the HTML getting parsed.
What could be the reason for this? What do I do to parse PHP directly ?
Note: I have installed XAMPP, and the path I give in the above snapshot is of the PHP interpreter that comes packed with the XAMPP package.
Ensure that the tomcat webserver is stopped and the XAMPP server running, since there could be a conflict (of ports, URIs etc).
If XAMPP is running and it still doesn't work, you can try the following:
Ensure the webserver has the type set in conf.d:
AddType application/x-httpd-php .php .php5 .phtml
Also, if you are using short tags make sure it is enabled in php.ini
Make sure mod_php is enabled in XAMPP (should be by default). You can do this by navigating to httpd.exe in XAMPP and typing httpd -M which will list currently used modules.
I'm trying to redirect my response but I got stuck at the link path.
The following command takes me to the tomcat's localhost and searches for the page there but it can't find anything, as expected.
response.sendRedirect("/myPage.html");
In order to manage this problem I have to put my root folder name (the one from webaps) in the link path, but I don't think that's a really good idea.
response.sendRedirect("/mySite/myPage.html");
Why is this happening? Is there any other way to solve this problem, besides getRequestURL() or something like that?
A relative redirect URL is relative to the current request URL (the one as you see in the browser address bar). The leading / will take you to the domain root. The behaviour is perfectly predictable and normal. If the myPage.html is in the same folder as the current request URL, then you can just remove the leading /:
response.sendRedirect("myPage.html");
Or if that is never reliably predictable because the current request URL can come from anywhere in your webapp, then just dynamically include the context path:
response.sendRedirect(request.getContextPath() + "/myPage.html");
I have site say http://info.sys.com
I want the info in the url to be replaced to knowledge.sys.com when i select knowledge tab in my website.
info.sys.com should be replaced to knowledge.sys.com when i select knowledge tab.
I use jdk 1.5 update 9 and tomcat 6.0.16
Looking forward for your reply.
If you change the URL (location.href = 'http://knowledge.sys.com';), the page will be reloaded -- well, actually, the page at that address will be loaded (whether that's the same page or not will depend on your server).
There are games you can play with anchors, though (the "hash" part of the location). Check out Really Simple History for more on that.
Changing the URL field programmatically on the client-side will trigger the browser to refresh the page with the updated URL.
This is considered a security feature which guarantees that the URL field is always showing the address of the rendered resource.
You can use a URL Rewriting Engine on your server if you cannot host your knowledge base at knowledge.sys.com. This could be configured to handle requests to knowledge.sys.com without having to change your application file structure.