I have an ASP.Net(VB.Net) project which has various modules/functionality. I want to give users the freedom to set their own default startup page.
I don't know how to get a head-start implementing this feature.
Also, I am NOT using MVC
On the master page place some control to choose current page as default (i.e. button or checkbox). After user has select current page as default you can store the page address to user's profile or any storage you like.
Set the site start page like Default.aspx and in the Page_Load method of this page read user's saved default page if exists and redirect to it.
You'd want to set up a way for the User to store their preferred home page in your database (or your preferred method). Once that's done you should be able to do this in a simple fashion:
ASP.NET WebForms:
On the Master Page / Default page, check to see if they're logged in in your Page_Load event.
If they are, check to see if they have a start up page saved, if they do then use Response.Redirect and send them to their preferred location.
If they don't, or aren't logged in, then show them the default page.
ASP.NET MVC:
On the HomeController's Index method check to see if they're logged in.
If they are, check to see if they have a start up page saved, if they do then use RedirectToAction and send them to their preferred location.
If they don't, or aren't logged in, then show them the default view.
There are probably plenty of other ways to accomplish this as well, but this should be a straight forward way to get your started.
Related
I have a master page which has a rather simple menu system. The menu items available are based on the logged on user. However, the database calls to determine this logic are over a second which is probably too long for my liking.
Is there a way to wrap the Menu into a UserControl but along with having a duration to refresh but obviously also the output cache should be on a per user basis?
I know the other solution is to cache the data for each user and then rebuild but I thought the more efficent place to start would be Page Output cache.
Please note also this application does not user Session state.
You can look at VaryByParam method of Page Output Caching.
When your user logs in add a query string to your page something like page.aspx?uid=x123
then add the following to your page:
<%# OutputCache Duration="10800" VaryByParam="uid" %>
This will make it per user cache.
Do remember:
Even if you put your user as a query string, still do the validation, that its the same user who logged in, to avoid users peeking into each other's view by simply changing the query string.
I have a asp.net webpage that displays a link Login or Logout depending on a session variable "IsLogged". I want to implement caching in that page. But after applying caching the Login/Logout becomes inconsistent with the session variable. What is the best approach to address this problem so that I can also apply caching in that page?
Thanks,
Partha
I am not sure how you are caching specifically but you could break your page up into two user controls (ascx).
Your aspx page could contain the user control to that shows the login information (make sure that when you load the user control with a dynamic url so that the caching ignores it because the address is diff everytime like:
yourSessionInfo.ascx?stopcache=32487239875 (the number could be just current time in ticks)
You just need something that changes in your url so that the page 'looks' like it is different and reloads.
Then have the rest of your page in another user control that has a static url:
yourRestOfPage.asx
Notice nothing changing in the url so page can be cached.
Not sure if this will solve your exact problem but it should at least start you down the right path.
I'm doing some brainstorming for a portal framework, and I'm envisioning a breadcrumb navigation stack that is tracked via the ViewState (so that if the user clicks "back" in their browser and clicks some other link, the breadcrumb trail will depart from the right page). My pages are really just ascx controls that get loaded into a placeholder control on the main portal page based on the URL. When the user clicks a portal link, there is a postback that loads the original page and invokes the given link's "clicked" handler, which should then "push" the current location onto the breadcrumb stack before sending the browser a redirect instruction to change the URL to that of the page that I want to go to.
That's as far as my brainstorming goes for the moment, because once we perform a redirect, we lose the ViewState. Rather than doing the redirect, I've thought of simply telling my main portal page to replace the current page control with the target page control, thus avoiding the extra http round-trip and allowing me to keep the ViewState. But then my entire website experience occurs in the context of a single URL, so I lose URL bookmarking among other things. And if I wrap some of my controls in AJAX panels, the entire site happens in one page request as far as the browser's history is concerned.
What I would like is some way to have the browsing history and URLs behave as if each link is leading them to a new page with a descriptive URL and all that, but still have some way to know the path that the user took to get to the page that they're on (ViewState seeming to be the simplest way to track this).
Could anyone suggest some techniques I might try using?
First suggestion... You may want to look into ASP.NET MVC. However, I have to admit to some ignorance here as I'm not sure that would really solve your problem. But it sounds like the sort of thing MVC would be suited for.
Second... it's possible to override the methods responsible for saving and loading ViewState. One of the things you can do, for instance, is push the ViewState into the Session rather than sending it down to the user and back up on postback. You could easily add some custom code here.
Third... I think you may want to rethink part of your design. The ViewState really serves one purpose: It recreates the state of the page as it existed when the page was rendered for the user. If you are moving to a different page, or a new set of controls, why would you need the ViewState at all? The ViewState itself is really just a hack to begin with... ASP.NET's way of maintaining state on top of a stateless system. (but that's a whole 'nother discussion) We have other methods of maintaining state... the primary mechanism being the Session object. Why not save your breaacrumb data there instead?
I would look at using cookies. For performance reasons, you really want to avoid HTTP redirects if you can, and ViewState only works if the user submits a form, not for regular links.
You might do something like maintain several path lists in cookies that show the path that the user took to go from one page to another. Maybe you set a unique ID with each page that is applied by some JavaScript as a query string when the user clicks on a link, and the server uses that ID and the past history from the cookies to determine how to render the bread crumb on the next page?
I have an ASP.NET website with some independent sections. I need a way to turn on/off the different sections (each section is in it's own directory) based on the user selection. How can I prevent the users from accessing sections that are turned off?
The solution I ended up using was to make a new class ModulePage that inherited Page. In the OnInit it would check an Abstract property I added IxModule to see if that that module was turned on or off, if it was on the page will display and if it is not the user is redirected to another page. Each page in each module has to be change to inherit ModulePage and then just specify the IxModule value. It is working very well.
you can require a log-in for those pages. I'm not sure if that's what you want.
You could look for a specific web.config app setting for each section. Each section would need a web.config setting with a sectionID app setting element.
If your using master pages, just do a check in the master's on PageLoad and check to see if the user has access to the sectionID store in the config setting. Store the section IDs that the current user has access to in the session or a cookie or something (not sure what type of security your looking for). Have one global function to lookup the app setting from the web.config. Depending on which page is calling it (from which directory) you will get the specific section's ID.
If the user does not have access redirect or show a message or something.
I have 3 asp.net pages: Search.aspx, Results.aspx and Login.aspx.
Now I want anonymous users to be able to search, so everyone can use search.aspx. This page calls
Server.Transfer(Results.aspx)
and therefore shows the results. Now when the user is not logged in, a link to the login page is displayed on the Results page. The problem is:
After the login, I want the user to be redirected automatically to the Results page. However I do not succeed so, as the PreviousPage property of Login.aspx is always null. And when I use
Request.UrlReferrer.LocalPath
it's the link to Search.aspx but not Results.aspx.
Also, when the user is on the Results page, how do I enable him to go back by clicking a link and all his search input criteria (like in textboxes) on the Search.aspx is still there so he can refine the search after having seen the results? Whenever I send the user back, all user input is lost.
I still haven't figured out if I should use a normal hyperlink, a linkbutton and how to retrieve the previous page url or preserve the input data.
I can use AJAX if that is any help, but a "pure" asp.net solution would be preferred.
When you do a Server.Transfer it is a serverside redirect...meaning the client still sees the original URL. You need to post the search criteria to the results page, store them locally, show the login link. When they are logged in you can redirect to the results page and rehydrate the search critera and show the results.
Try using Response.Redirect("url") instead of Server.Transfer. When you use Server.Transfer, the url on the client will remain the Search page and not actually redirect to the Results.
You can use User.Identity.IsAuthenticated to check if the user is logged in and show/hide the login button based on that.
To keep values for the page, you could store them in Session, then have the Search page look for them and, if they exist, place them in the controls.
You can also embed the URL you want to return to after login into the querystring if you want.