Tag: forward

Redirect within a javascript file

There often comes a time when you are working on a large project and find a need to refactor javascript resources. Unfortunately, if those assets are accessed by 3rd parties or other code you cannot easily update, you might find yourself stuck.

If you have access to the Tier1 (HTTP server such as ApacheHTTPd) you can often do this within the httpd.conf, or an .htaccess file update. If not, you can always do a simple function within the old javascript file itself, such as the one below.

Put this in the old javascript file location, it is in a closure to prevent the variables from “leaking” into the global namespace.


/* MOVED */
(function(){
"use strict";
var u='/js/newfile.js';
var t=document.createElement('script');t.type='text/javascript';t.src=u;
var s=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(t,s);
})();

Comcast Business Class gateway forwarding port 22 for SSH

For as long as I’ve had Comcast, and other providers for that matter, I’ve been able to configure my internet gateway/router to allow port 22 (SSH) access to an internal machine. It came as a surprise to me earlier this week that I was blocked when I tried to use their web admin console to change the internal forwarding to a newer machine. As usual, Technical Support was less that helpful and said that it was not possible to do so, and never should have been as Comcast uses that port to administer the gateway. To make matters more disturbing, I was told that I could not have similar SSH access to the gateway, and that replacing their hardware, while permitted, would prevent my use of a static IP.

Back to the solution, as I know that I had only setup this forwarding about a year ago, and it was working only minutes before I tried to change it, I knew that the configuration was possible if I could figure out how it was being blocked. The message in the web console was a javascript alert(); and gave me a starting point. I opened up Firefox and used Firebug to look for the message. Here are a few interesting findings from:

http://HOSTNAME/user/feat-firewall-port-forward-edit.asp

var RemoteManagementPortsCgiBase = “8080,8080,1\|8181,8181,1\|2323,2323,1\|22,22,1\|”;
…
msg += “Public Port Range conflict with Remote Management Ports.\n”;
…
if (msg.length > 1)
{
alert(msg);
return false;
}
return true;
}

If you even a little bit of javascript (or simple computer programming for that matter), the solution is clear…. if the ‘msg’ value is empty you will not see the alert or be prevented from making the change you desire.

Lesson to be learned by the Comcast developers (or most likely = subcontractors), always validate submitted form data in your application code, NEVER rely upon javascript alone to verify user entered data!

I also find it interesting that they are also preventing 8080, 8081 and 2323… perhaps that’s their other back doors in these gateways for their access. The same approach should work for those ports if you need it!

HTTP Forward vs. Redirect

A Controller servlet may perform either a forward or a redirect operation at the end of processing a request. It is important to understand the difference between these two cases, in particular with respect to browser reloads of web pages.

Forward

  • a forward is performed internally by the application (servlet).
  • the browser is completely unaware that it has taken place, so its original URL remains intact
  • any browser reload of the resulting page will simple repeat the original request, with the original URL

Redirect

  • a redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original
  • a browser reload of the second URL will not repeat the original request, but will rather fetch the second URL
  • redirect is marginally slower than a forward, since it requires two browser requests, not one
  • objects placed in the original request scope are not available to the second request.

There are several ways to perform a Redirect, here are a few common ones:

  • URL Redirection (HTTP 301): 
    HTTP/1.1 301 moved permanently

Location: http://www.example.org/
  • HTTP Refresh Header (Not Recommended) 
    HTTP/1.1 200 ok

Refresh: 0; url=http://www.example.com/
  • HTML <meta /> tag 
    <meta http-equiv="refresh" content="0; URL=http://www.example.org/" />
  • JavaScript (many possible solutions, generally not accessible or searchable) 
    <script type="text/javascript">location.href='http://www.example.org/';</script>

In general, a forward should be used if the operation can be safely repeated upon a browser reload of the resulting web page; otherwise, redirect must be used. Typically, if the operation performs an edit on the datastore, then a redirect, not a forward, is required. This is simply to avoid the possibility of inadvertently duplicating an edit to the database.

More explicitly :

  • for SELECT operations, use a forward
  • for INSERT, UPDATE, or DELETE operations, use a redirect

In HTML, a <FORM> tag can either GET or POST its data. In this context, a GET corresponds to a SELECT-then-forward, and a POST corresponds to an edit-then-redirect.

It is strongly recommended that forms for the input of search criteria should use GET, while forms for editing database records should use POST.

SECURITY NOTE: When using GET, be sure to not expose sensitive data in the URL’s.