Develop Reference

How to prevent manual URL change from reloading the angularjs application?

I'm trying to hide a sensitive data from the url from a incoming href redirect. The problem arises when the url is manually changed from inside the angularjs controller, which leads to the page reloading.
Catch: I do not have control to add code to the application that has the href containing the url.
For eg:
external url redirect"www.sample.com/subpath?sensitiveNumber=123456789"
I expect the url to be changed to
"www.sample.com/subpath"
I did try to reference solutions from the following SO thread:
Can you change a path without reloading the controller in AngularJS?
problem at using reloadOnSearch is when another url comes with a different url data as parameters, it would not reload with the new data.
another method I tried was to store the incoming data into a localStorage of the browser, so that it is not necessary to know the sensitive data when the page reloads on url change; but that would result in all the Async functions to be recalled, impacting performance.
Here is the routing snippet of the current code
.when('/subpath') {
template: '<templatePath>',
controller: '<controllerName>',
reloadOnSearch: false
}
thanks in advance

change get request to post request.So that data is not sent in the url.

Thanks for the responses. The only way we had to overcome this issue is provide and encryption service in between the service layers and performed decryption in our application front-end. As of this date, we do not have a correct verified solution for this problem

Do javascript after redirect

I redirect to a new page with javascript as
window.location.href = new_page;
When the new page loaded, I want to run some javascript functions.
However, how can I detect when a page loads, it is from my above redirect?
I consider two options: creating a session or passing variables via the URL as
window.location.href = new_page+'&redirected=1';
Then checking if redirected query is set on each page.
I wonder if there is a simpler or more standard approach to do so?

Passing parameters throught URL works fine, but it's not a pretty good solution. I suggest you to try local storage, with this solution you even could track from and to urls the user has been redirected.

HTML/Javascript: How to control refresh action without re-submit the form

We are trying to implement a web page that each time of page refreshing will not result in the form resubmit, how to achieve that? Is there any Javascript code or HTML can make it WITHOUT external javascript library(jquery, dojo or extJs)
The reason of such design is that the form is going to tie an unique relation to current data with means cannot do it twice but for security reason we have to use POST instead of GET, also after the action we still want to preserve user the right to do similar action on the same page to another relation. so how to avoid a consequence like that?
Thanks.

Suppose that the action to the form submits it to submit_form.php. That file can handle the data and do whatever it needs to do. Then in it's response, it can redirect the browser to a separate page (you'll have to look up the exact method of how to do this depending on what language you write your POST handler in). This separate page can show the results of the form submit using session variables or some other method.

When is a postback not a postback? (according to ASP.net)

Is there a difference between me using Javascript to redirect to URL + "?Querystring=value" versus using whatever mechanism ASP.NET uses?
If there is a difference, how can I make the rendered ASP.NET page be submitted to the same URL with a different query string by javascript?

If you want to do a post back just like a asp control like a asp:Button you can use the javascript functions included by the framework to do so:
__doPostBack('ControlIDOfEventYouWantToRaise','');
You can read more about the __doPostBack in this article:
Doing or Raising Postback using __doPostBack() function from Javascript in Asp.Net
Just doing a form.submit() will not be exactly the same as using __doPostBack.
To answer the first part of your question there is no difference doing a redirect if you are just doing a Response.Redirect as the will both do a GET. The difference is if you use a asp:Button control for instance, it will access your page first to handle the button (a post back) and then do a GET on the redirected page.
If you want to submit to the same URL (eg post your data) then you should use the __doPostBack method. If you don't require the data to be posted, then just do a redirect in javascript to the same URL with a modified query string (which will just do a basic GET) but your data will not be posted.

The only potential difference is that a querystring parameter is sent via GET, a form is (usually) sent by POST.
GET has a much smaller data limit as browsers have a max URL length (it varies)
You could use javascript to do a form.submit() which shoul emulate what ASP.Net does

I somewhat disagree with Basiclife's answer; if you have any code inside something like
if (IsPostBack) {
it's not going to be equivalent, ie the code is going to be executed if you're just setting the URL. Also, controls keep their state across postbacks but are freshly initialized if you're calling the URL again. This is due to ASP.NET trying to emulate a "normal" application, so the way to make sure a normal call and a postback have the same effect might result in "de-ASP.NET-ing" the entire page.
I'm not sure if what you want works. There probably is a way. But I heavily suspect there's a better way of doing this. If you get a postback for free, and can transmit data, why is it crucial that the data shows up in the URL, instead of being comfortably posted? I can see how you want a page to respond to a URL parameter, and how you might want to change the same parameter later on based on what's happening on that page, but since you always know you're posting back, you can eg override that URL parameter in that case, by something you're posting back. This doesn't sound so nice, but it might actually be less messy. Particularly since you seem to have a reason to not abandon the postback at all (otherwise you could just use a link, right?).

Javascript function execution on link click?

I have a link, that when a user clicks on it, it loads a different page as normal but also executes a JS function that autofills a specific text-box on that different page. Is it better practice to use Jquery or Javascript to do this? How can I do this using either one of them?

You can't do this from the source page.
It's a security feature. Imagine if you wrote a JS function that went to an online banking page and auto-filled a bank transfer using the user's current cookie. That's why you can't.
If you control the other page then the sequence you can use is:
Save data to the server;
Go to the new page with a JS redirect;
The new page is loaded from the server;
While loading th epage the data that was saved from the server is retrieved and used to populate the text box.
So it can be done from the server but only if you save it there. The only way of doing that is using Ajax.
An alternative approach is:
Instead of a JS redirect, submit the page back to the server;
The server saves whatever data it needs to;
The server sends back an HTTP redirect to the new page;
The new page uses the saved data to construct the new page with the populated text box.

At the end of the script add return false;. This will make the page run the script without redirecting the page.
Edit: (after saw your edition).
Is it better practice to use Jquery or Javascript to do this? How can I do this using either one of them?
jQuery is a javascript library, this it doesn't matter if you use plain javascript or use jquery as long as you happy with the result.
And about what you say that you successfully manipulated a page fro the redirecter page... I don't see how it possible.