Global.asax and user visits - global-asax

I'm trying to dig around into an idea where we want to close a webiste for upgrades. So when a user hits our site, they are promptly re-directed to a page that tells them that the site is down for maintenance.
Theoretically, the entire process starts in the global.asax under the event session_start. We fire a command to the webservice to see if the service is down - if it is down, a false value is returned and the user is rerouted to a page that says the site is down otherwise normal operations continue. This is a non-password site.
Here's the idea with pages:
welcome.aspx
siteisdown.aspx
page1.aspx
page2.aspx
When the user visits the site, the code checks to see if the rest of the site is down for maintenance and if so, then the user is re-routed to siteisdown.aspx
We have that basic part down - but the real understanding is, the user - while still in the siteisdown.aspx page, could enter page1.aspx and continue on their merry way.
What we want to is is if the user enters page1.aspx they should be kicked back to siteisdown.aspx
What articles should I be looking at for this type of method? Forms Authentication?

There is already a feature for this built in. Deploy a static HTML file called "App_Offline.htm" to the root of your application and all requests will be routed there.
http://weblogs.asp.net/scottgu/archive/2005/10/06/426755.aspx

Related

UWP: Calling Frame.Navigate() from a Page.OnNavigatedTo event

Into an Universal windows app I want to check user's authentication during page load, or after that an user as navigated to. This permits me to offer a navigation filtered by authorizations with a single page granularity.
For example, if an user didn't login and a page requires authentication, user has to be redirected to a login page.
The problem comes when I try navigate to an other page from the OnNavigatedTo event, when previous navigation is not completed and the new fails. I've searched for other events like an OnNavigationCompleted, but I don't find anything. If I use an asynchronous method without waiting it works, as if I use a timer dispatcher, but both solutions doesn't sound like so clean.
Exists a method to handle an event raised after navigation completed or I have to pre-check authorization during navigation call? I hope to avoid this solution because a wrong call could show an unauthorized page.
If you really want a separate page according to this answer https://stackoverflow.com/a/19527979/4788286 you could probably use the loaded event. But I'd test it before just to make sure.
Sidenote: also, your question implies that you're doing business logic in the view codebehinds - this is bad practice, I suggest looking into the MVVM pattern. (If you need a framework I suggest MVVMLight or PRISM)
I think the precheck would be the best method. Check if they are authorized to view the page before they can navigate to the page. If they are not authorized ask if they want to log in or purchase rights to the page

Is it Good Practice to refresh the whole Page or Just reset the variables when user logged out (GWT)?

Here is my Gwt App, I have many pages: CustomerPage, OrderPage,... Each of these pages will have a header that have a Login Panel on top & its own content in the middle like this:
1- Customer Page
____________UserName...... Password....... Login
Customer Content here.....
2- Order Page
____________UserName...... Password....... Login
Order Content here.....
This means user can sign in in any page, they don't need to go to homepage to sign in.
Then here is my question, When user is in a certain page (ex: CustomerPage) & if they Log out then:
1- Should I refresh the whole page or redirect users to a Logout Page, so if they want to reopen the CustomerPage, then the page will have to go through all the Initializing processes (onBind-onReveal-onReset...)
2- Should I just let user stay where they are, and when user clicks logout button then system will reset variables. By doing that, then if user logs back in, the page will run faster cos it doesn't have to go through all the (onBind-onReveal-onReset...). However, if i do that then it quite difficult for me to reset all the variables. I have to remember which variables already initialed at the time the page got loggined & try to reset it to null or empty string. If i miss resetting just 1 variable then i will have trouble.
Some big site like Google or Facebook are using the solution 1, ie when user signs out it will redirect to new page or go back to homepage.
Also If adopting the solution 1, then i just need to call Window.Location.reload(); & it will reset everything. Even user clicks Back Arrow, they won't be able to see the old data since everything was reset.
So:
Is it Good Practice to redirect to a new Page or staying at the same page When user logged out (GWT)?
When users click on a Logout button, they expect that they can walk away from a computer. If you continue to show the same page, someone else might gain access to the data.
The universally accepted approach is to hide all data (i.e. redirect to the login/home page or close the app completely) when a user logs out. That's what users expect, and this is what you must do.
It depends what you've got loaded into the browser. Log in/out via a page refresh will be slower and present lag to your user. If you properly cleanup after yourself on logout (delete server side session, unbind presenters, clear caches) then it is really optional to refresh the page.
The universally accepted approach is to hide all data (i.e. redirect
to the login/home page or close the app completely) when a user logs
out. That's what users expect, and this is what you must do.
If your session management server side prevents any RPC's once you've logged out, and you no longer present/cache data, this is not an absolute necessity. Use digression based on your app needs, size, load time, and the sensitivity of the data it conveys.

Calling external logout within Classic ASP

basically what I am looking for is something like this;
I have a link on a classic asp site that calls an .ASPX file, which in turn sets a bunch of user credentials from Sessions variables and then re-directs to a third party vendor hosted site, dirty I know but nothing can be done about it now.
so the process is;
1. Loads classic asp page with link to .ASPX page
2. Clicks link, sends to .aspx page
3. .ASPX sets required data and .Send() to third party vendor application
the issue is that if the user doesn't "logout" of the third party site and goes back in under a new username, the first username credentials stay set. What I want to do is on the .asp page before the user clicks to go to the third party vendor app call the vendor apps Logout page in the background. I was thinking of using an iFrame, but an iFrame just displays the logout page, it won't actually execute the code that is associated with it.
Any help is greatly appreciated,
Nick G
Your Iframe method should work if you got the server side code correct. Two things to bear in mind though.
First, session variables are specific to domains, so if your pages are available via multiple domains and the src attribute of an Iframe is different to the one from which the user accessed your site to start with then your session data will not be recognised. This may even apply if one url includes the "www" and the other doesn't - I've never tested this
Second, Classic ASP files and ASP.net files can't share session variables, you need separate sets of variables for each set of pages. If you need to synchronise the two sets a common hack is to use a 0px by 0px iframe, eg
<iframe height="0" width="0" src="dotnetpage.aspx?userid=<%=Session("userid")&loggedin=<%=Session("loggedin")" />
Obviously dotnetpage.aspx would contain code to set the querystring values as session variables, and you can have a classic page receiving a querystring from a .net page
Whatever solution you come up with along these lines will only work as long as it takes for this third party vendor to realize they have a gaping security hole in their site and decide to close it.
One should never be able to log someone out of another system by injecting a hidden iframe in their page, for example. This is a form of a CSRF vulnerability and indicates a sloppy security posture by the other site.
I would certainly consider another approach.
I figured out a better approach with classic asp and just included the url as an and it seems to be working correctly.

What is the purpose of isFirstPageAfterLogin method in admin/session model?

I see where this method is being used, but I'm wondering who has an authoritative answer on the matter?
I know you said you know where, but I'm going to mention it here for completeness since you didn't... hope you don't mind! :)
The flag that isFirstPageAfterLogin() checks is set in the login() method that's called during the admin login process.
It is used in the following places:
Mage_Adminhtml_IndexController to store the value in the admin session so that it's still available on the first page load after the login form is submitted.
Mage_Adminhtml_Block_Notification_Window to determine whether or not to show the notices "window" that often shows after login.
A few actions on Mage_Adminhtml_Report_StatisticsController in order to redirect the user to the page they should be if their login routes them to one of the report refresh actions.
Mage_Core_Controller_Front_Action uses it to redirect a user back to the dashboard if their login routes them to an action that would send a download response, which frequently can rely on filter data that may or may not be available to the controller if it come from the login.
So to recap, it's a very important flag that is used to control some behind the scenes behavior. The most important being redirecting to the correct login page and allowing for one-time notices to show upon login.
This value is used in Mage_Adminhtml_IndexController, specifically the indexAction(), and redirects the admin user to the start up page defined in System > Configuration > Advanced > Admin > Startup Page.

Classic ASP Logout Process

I'm working on a web application developed classic asp. It has logout button on the top menu which basically does the following actions
Session.Abandon()
Redirect to Index.asp, where users can login again.
After logging off users return to index.asp. But if users click back button the browser, they go to previous page. I don't want this to happen. I want a message saying that they are already logged off.I have implemented following steps
1.Add Response.Expires=-1 and Response.CacheControl="no-cache" at the top of each page.
2.On each page i'm checking session object to see it is not empty. If empty i'm creating a message saying that they are already logged off and need to log in again.
Now when users click back button after logging off, instead off showing logged out message, i get "Web page expired" message on IE8. I see the same behavior when users click back button on some page while logged in.
Any ideas how i can implement this better.
Thanks.
You can't stop users pressing back. A common scenario to work around this is that POSTs target a server page that displays no output but redirects to a new location instead (where the results can be seen).
There are additional non caching declarations that sometimes help:
Response.Expires = 0
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
I did read some time ago (hence inability to find link) that setting an expires to -1 can cause some browser to ignore it rather than have it expire immediately.
Even adding these extra cache controls won't stop some browsers from caching some things some of the time. FF quite often ignores a forced cache reload by the user, so you are in the browser makes hands to a certain extent.
Regarding your "Web page expired" message, this is (as mentioned) the result of the browser trying to stop you from resubmitting POST data (and potentially duplicating what you last did). The best way to get around this, and solve a number of other common UI issues on forms is to POST back to the same page, then if/when the action is completed, using a response.redirect to the same page, maybe with a URL encoded message to say "all done successfully". This allows your users to refresh and helps with the back button issue as most browsers now don't store properly redirected pages in their history.

Resources