Problem with AddMenu Items in ASP.Net Application - c#

I am generating menus and sub menus on the fly in my Master Page.
I have a link which points (AddMenu, and give url to the logoff page) to a generic logoff page. It is a html page. Before logging off, I make sure that the Sessions are aborted and cleared.
When I deploy this application on Servers, the application fails to come up.
To correct, I add a new aspx page. say Logout.aspx
When I click on Logout link on the master page -- I add menu item -- to point ot Logout.aspx.
In the Page_Load event of Logout.aspx, I clear the sessions and then Response.Redirect to the logoff page (which I was doing in the Master Page initially).
This case the sessions are working perfectly fine. What could be the possible reason for it?

From what I understand it sounds like you initially were trying to clear the session in the master page code-behind. This code was supposedly tied to the logoff menu item but you said the item was a 'link which points to a generic logoff page'.
My guess is you were expecting the link to trigger a postback to the masterpage when it was actually just directing the user to the html page.
When you moved the code to the Page_Load of the new Logoff.aspx page, your session clearing code was triggered correctly when they requested the Logoff.aspx page.
If this is the case, what you have found is that there is a big difference between the following
Logoff
and
<asp:LinkButton ID="linkLogoff" runat="server" Text="Logoff" />

Related

Url of Home.aspx page automatically convert to Default.aspx

I am developing a web application webform project. I have few web forms in it. I have some anchor elements that are performing redirection of pages. First let me show you the structure of my project:
I am trying to navigate to Customer/Home.aspx page from Login.aspx Page.
The issue I get is it automatically converts Home.aspx to Default.aspx. Here is how it resolves the Url:
And here is the html I am using:
<ul>
<li>Customer</li>
<li>Products</li>
<li>Sales Order</li>
<li>About</li>
</ul>
How should I resolve these urls correctly?
UPDATE
I already have tried to use the LinkButton control but the Issue remains the same:
<li>
<asp:LinkButton ID="lnk" PostBackUrl="~/Customer/Home.aspx" runat="server">Customer</asp:LinkButton>
</li>
based on my experience I'm providing you with the following solutions.
The solution can sometimes be simple. Just try the clear the browser catch files.
Right click on the start up web form (in your case guess it's 'Login.aspx') and click 'Set as start Page' before compiling.
Try to place '../' before the url like (../Customer/Home.aspx). But this cannot be the issue unless you're trying to redirect from inside a directory.
Please do reply me if this didn't solve your problem and check the URL on the HTML source code of your page, try to attach a screenshot if possible.

Page redirection not hitting break points in Visual Studio

I have a survey application which user fills the info and then clicks Submit and gets redirected to other page(Success.aspx) which simply shows a message
"Survey was saved!"
After that I want to redirect user automatically to the login page. I found the following code:
<meta http-equiv="refresh" content="3;url=Login.aspx/" />
Above code "Does" work. User gets redirected to login.aspx after 3 seconds, however code does not break in Visual Studio(2013) anymore. If user tries to login, code directs him to the survey page Response.Redirect("Survey.aspx")
but the break point that I put in the load even of that page will no longer works.
If I remove
<meta http-equiv="refresh" content="3;url=Login.aspx/" />
Breakpoints work again! Is this a known issue?
You are getting confused between a ASP.Net postback and a classic HTTP Request (in this case a GET)
Only ASP.Net does a postback, this is a none standard interaction triggered by a __doPostback() JavaScript call that comes bundled into ASP.Net.
What the meta tag does is a standard HTTP GET.
The difference (in your particular scenario) is that the postback will hit the calling page when something happens (the client triggers a HTTP POST to the server and ASP.Net handles the call) where as the meta will simply trigger a GET to the new page (the client simply calls the new page and does not interact with the calling page)
Hope that explains it.

Set Page to redirect after login in aspx

I use a System.Web.Security.MembershipProvider to do my login-stuff on my aspx-Page.
My default page is stored in Pages/Default.aspx.
I defined this page as default page in iis. When I call my page via server/Pages/Default.aspx and do the login, everything works fine.
But when I call only server and do the login here, I'm redirected to server/Default.aspx (without the Pages-directory) -> which leads to an error, page not found...
Is there a way to prevent this, without changing the folderstructure of my project?
EDIT:
My Login-Control on the master-page:
<asp:Login ID="LoginBox" runat="server" Width="339px" DestinationPageUrl="/Pages/Default.aspx" FailureText="Username or password wrong!">
I think you need to find the application context folder structure code on the aspx page,
please refer this :
How to get the physical location of an ASP.NET web application without using HttpContext.Current?

how to prevent data from sending if user press F5 or refresh in asp.net?

I had asp.net form app I have a bug when the user click F5 or refresh it will enter the data from last data entry .is their is away to Prevent sending data if user click click F5 or refresh?
It's easy to reset a page to it's initial state in ASP.NET by redirecting to itself. Here are 3 ways you can do it:
Response.Redirect(Request.Path);
In which the path to the request is presented in the following form: /MyApp/MyFile.aspx
Response.Redirect(Request.RawUrl);
In which not only is the path exposed, but also any querystring parameters like:
/MyApp/MyFile.aspx?foo=bar
Response.Redirect(Request.Url.ToString());
In which not only is the path and querystring parameters exposed, but made available as an absolute reference in the form:
MyServer/MyApp/MyFile.aspx?foo=bar
A common solution to this is called Post Redirect Get (PRG), where the browser is immediately redirected to a HTTP Get page after any post. See Post Redirect Get in asp.net for a web forms implementation.
There are multiple ways to prevent this from happening. The simplest is to Response.Redirect to a another page, which can be refreshed without consequence.
// process form post
Response.Redirect("anotherpage.aspx");

C# - If user refreshes page after inserting a record, a duplicate record is created. How can I prevent this?

This is true with any other functionality present on the page. I don't want the last event that happened before post back to happen again.
I believe you should take a look at the PRG Pattern (Post/Redirect/Get)
Post/Redirect/Get (PRG) is a common design pattern for web developers
to help avoid certain duplicate form submissions and allow user agents
to behave more intuitively with bookmarks and the refresh button
In ASP.NET:
POST - Submit button click causes HTTP POST
REDIRECT + GET - HttpResponse.Redirect()
MSDN, Redirecting Users to Another Page
In server code, you can programmatically redirect by calling the
Redirect method. The method sends a command to the user's browser that
causes the browser to issue an HTTP GET command for the target page.
Few important notes regarding PRG pattern:
!!! The PRG pattern cannot address every scenario of duplicate form
submission. Some known duplicate form submissions that PRG cannot
solve are:
if a web user goes back to the web form and resubmits it.
if a web user clicks a submission button multiple times before the server response loads (may be prevented by using JavaScript to disable
the button after the first click).
if a web user refreshes before the initial submission has completed because of server lag, resulting in a duplicate HTTP POST request in
certain user agents.
if a malicious web user submits the form twice despite client-side safeguards and typical browser behavior.
You should learn about the PRG (Post/Redirect/Get) pattern:
Post/Redirect/Get (PRG) is a common design pattern for web developers
to help avoid certain duplicate form submissions and allow user agents
to behave more intuitively with bookmarks and the refresh button.
Source: http://en.wikipedia.org/wiki/Post/Redirect/Get
Basically you'll want to redirect via a GET request after the user has done a POST.
you can check already exist condition before inserting record in Database.
like in stored procedure you can check
if not exists (select id from table where column name ='test' )
begin
inser statement..
end
This is about PRG. The simple way to avoid this is redirect user to same page again:
Page: Update.aspx
void btnUpdate_click(object sender, EventArgs e){
// do your update here
Response.Redirect("Update.aspx");
}
This will create a redirect-header in Resoinse and browser will create a GET request to Update.aspx page. And if the User refresh the page, a GET will be sent. Look:
User submit the form : POST
Server do updates, return a redirect-header
Browser receives the response as a redirect-command : REDIRECT
Browser sends a GET request for same page to server : GET
Browser receives the response answered by a GET
If user refreshes the page: Browsers last command was GET, so will not fires a submit again
A simple way is to use javascript to disable the button when the users click it.
A way I use to avoid refreshes when high security is needed, is the use of a small "token" in session.
Let's say, we put a small 32 bit integer in our session.
The page will contain an hidden input containing our small integer token.
Each time we receive the page request, we increment that token by one, and, before doing so, we check for equality with the one received in the request.
If they match, it is not a refresh.
If they don't match, it is a refresh.
This will also block attempt to do back and next with browser buttons.
Of course at the point that token don't matches, the page should change or you'll have again the refresh problem.
It should show something like "hey, refresh back or next not allowed, press here to continue".
For increased security, you can xor that integer with a costant value dependant for example on some other value that is constant in session.

Categories