Is there any way for one user control to raise an event that is handled by another user control without going through the page? I am using Umbraco and do not have access to the page object.
--Edit--
Umbraco has the idea of Macro's (user controls) that it loads into pages. I can't access the page directly as this is part of the framework.
There is a publish subscribe (pubsub) pattern that I know would fit my needs well (2 user controls that need to talk to each other) but am unsure how to hook it up in ASP.Net without the page object.
ANy help would be really appreciated.
I'd recommend that you use Webforms MVP if you want to do that, it has a concept of cross-presenter messaging, allowing you to raise a message on one presenter which is consumed by another.
There's a video of how to use it on their site.
Related
I'm currently developing a website using Visual Studio 2010. As you all might know, creating a new website here automatically adds an Account folder which contains webpages like Login.aspx, etc. I am implementing this Login.aspx which contains the ASP.NET Login control. It's now functioning the way it should but I have a few concerns.
Before, I used to create my own UI for the log-in so managing sessions is not a problem to me. But since i'm currently using the Login.aspx which has a CS file almost empty, i don't have an idea where I can start implementing my session. Meaning to say, I don't know how to check programatically if the user has been successfully logged in so I can start implementing my session.
I would very much appreciate any pointer regarding this matter.
Thanks in advance. :)
You could subscribe for the Authenticate event and perform some custom authentication logic. Also you may take a look at the following article.
There are events associate with ASP.NET Login Control that you can use to create session like OnLoggingIn. Moreover you can find more about user validation from here Validating User Credentials Against the Membership
I'm a PHP developer who has to work on ASP.net projects and I'm wondering why every page is wrapped in a form. This just doesn't make sense to me.
Also What's with all the hidden input fields especially the "View State" one.
ASP.Net tries to make it so that the programmers can pretend that the web is a stateful platform, and that it behaves like a desktop application. The ViewState is basically a serialized block of the state of the page when it was generated. When the page gets posted back the server side model gets initialized to the values in ViewState, and then the new values from the posted form are applied.
Part of becoming a decent ASP.Net programmer is learning when to use ViewState and not, because the default is to use it everywhere which causes a lot of bloat in the downloaded page.
Every ASP.NET page is wrapped in a <form> element because the entire framework revolves around POST commands.
ASP.NET provides 'web controls' which are object-oriented abstractions of HTML elements (and in some cases, groups of elements) - in your server-side code you can attach commands to various events on web controls (for example, Button.OnClick, TextBox.OnChanged) - the framework wires these up using a combination of hidden fields and generated javascript. The generated javascript typically sets a hidden field few values to indicate (for example) which control triggered the post and the command arguments (if applicable), then submits the form.
ViewState is a technique used by the framework to serialize client state. It's an alternative to using session heavily, trading larger HTML payloads for a lower memory footprint on the server.
Everything in ASP.NET (aspx pages) works off of posting data.
This means that anything you place on the web page with a server-side action will cause a "post back" to itself. The post back contains information such as "what just happened" and some information that helps the web page to maintain state (which web pages don't traditionally do). The view state is part of that task of maintaining state.
If you don't like the way aspx pages try to turn web-pages into forms-style stateful applications, you can try out the ASP.NET MVC framework, which lets the web work as intended!
ASP.NET WebForms engine creates a stateful abstraction over stateless HTTP.
The key object is a server page. Controls fire events that are processed server-side. Controls maintain their states (usually, input values) between requests.
Any time you click a server control, a "postback" request is sent back to the server. ViewState actually contains the data telling the server what control fired the event. That is why there is always a form (and any more forms are not allowed).
Currently, we have a site where almost all the pages fall into some page class that's a subclass System.Web.UI.Page. Generally the subclasses control styling -- headers, footers, etc. -- things displayed on that class of page that we want for all classes.
For one particular class, we check some session variables to see if the user has access to that particular page. If not, they get redirected off and told they don't have access.
I've since implemented a custom role provider and am in the process of updating all my web.config files from to .
The question has arisen: Why not implement the page-based restrictions in the page class instead of implementing a role-provider methodology.
Honestly, when I first considered this topic, it seemed to me there was a clash between and having page classes do the authorization. However, I'm having a difficult time coming up with reasons why page-class based authorization would be a bad idea right now.
If you're able to understand what I'm talking about where we set access (authorization) info during the login process and then use this (session based) information to "authorize" a user to access a page based on the page-class vs using the built-in ASP .NET role provider methodology, I'd appreciate your thoughts on this matter. Especially if you have experience in this area.
Thanks.
Well both ways are possible, IMHO, it comes down to whether you want to use the ASP.NET authorization scheme (allows, denies in the web.config) or code it into the page.
Personally I prefer the configuration approach, as it is more flexible and allows for the pages to inherit from another page class, or use master pages to provide for a common look and feel.
I'm very new to the whole Ajax/Asp.Net stuff so...
I know that there are at least a few different ways of implementing the server-side of an Ajax enabled Asp.Net site.
One way is to add static methods to your aspx page's code-behind and mark them with the WebMethod attribute.
Another way is to use a separate ASMX web service file (which I don't know anything about :) ).
What are the most commonly used options for implementing the server-side? What advantages and drawbacks does each one have? And how does each one fare from a security and session perspective? (Making sure the server knows which session the Ajax request is from and ensuring only logged-in users are responded to?)
Typically I like to use jQuery to make the requests to .ashx page that is responsible for reading the data and passing back the JSON to the page to deal with. It sounds like the other options you suggested are pretty complicated by comparison.
The two most commonly used options are
Microsoft ASP.Net AJAX
JQuery partnered with webservices or request handlers (like Jon's answer)
Microsoft's ASP.Net AJAX is a framework that revolves around two server controls - the ScriptManager and the UpdatePanel. It's a bit more heavyweight than other options, but it's certainly a simple way of ajaxifying your site. You simply use an UpdatePanel to surround the portion of the page that you wish to be asynchronous, and all your controls that do postbacks (buttons, links, etc.) automatically become asynchronous requests that will only update that portion of the page. No coding or anything.
If you do plan on using the webservice route, ASMX is not the way to go - it's basically a "legacy" technology at this point and you should consider using WCF services instead.
I was wondering if it is possible to do a RedirectToProvider and have the resulting OpenID provider page displayed in an iFrame. This would make the authentication flow seem a lot more streamlined.
I am using the DotNetOpenID library in ASP.NET MVC (VB).
This next part is sort of a seperate question, but is related.
I am using Ajax.BeginForm for the OpenID sign in form, however the RedirectToProvider fails here for some reason. Does DotNetOpenId not work with MVC and AJAX?
Yes, DotNetOpenId supports iframes, MVC and Ajax. The OpenIdAjaxTextBox control that ships with the library and is shown used in one of the samples demonstrates this. It does not use iframes to display anything. It uses them with checkid_immediate to attempt implicit login without any user interaction, which is the only iframe-scenario that OpenID intends to support.
The IAuthenticationRequest.RedirectToProvider method internally invokes the ASP.NET Response.Redirect, which itself throws a ThreadAbortException, which might be why it seems to be failing for you, when in fact it's probably working by design, but that design conflicts with what you're probably trying to do.
There are various approaches to take to get what you want done, but as Workshop Alex has already suggested, there is a security concern with hosting the Provider's page in an iframe. It's not that the RP can access or mettle with the content of the iframe, because as EFraim said unless the browser has bugs that would not be allowed anyway. The two problems with it are Clickjacking and that you're training the user to be phished, since he will likely be providing his login credentials to his OP while the RP's URL is in the location bar, which is a bad thing.
And in fact, major OPs now deliberately refuse to work when they are activated within an iframe, so after the work to get it all to behave the way you want, you'd likely be disappointed that most of your customers won't be able to login.
Also as you point out, popup windows, when done properly, can help keep the experience user friendly. You can achieve this a few different ways with DotNetOpenId as well. The ASP.NET controls that come with the library have this feature built in and can be activated by just setting a property on the control. But since you're using ASP.NET MVC (I think), here's how you can do it yourself:
When the user clicks the Login button on your page, rather than POSTing to the current window, have Javascript that opens an appropriately sized popup window at a URL like http://yoursite.com/openid/redirect?id=userSuppliedIdentifier.
Your OpenID controller's Redirect action will read that ID, do an OpenIdRelyingParty.CreateRequest on that ID, and return IAuthenticationRequest.RedirectingResponse.AsActionResult() (MVC style). Note you can pass your own URL to CreateRequest for a returnTo url if you want the OP's response to come back to a different method on your OpenID controller.
When the assertion comes back, your controller should send down javascript that closes the popup window and (as necessary) communicates back to the main window to update its state for the logged in user.
This whole process is completely automated in the ASP.NET controls that DotNetOpenId ships with. It's unfortunate that ASP.NET MVC cannot be made as modularized as ASP.NET web forms so that you don't have to do all this work yourself. Of course, the MVC sample that DotNetOpenId ships with could be made to show how to do popup behavior in a future version. If you want that, file a wish for it.
Question is, would the OpenID provider consider this a security risk or not? If the provider page is inside an IFrame then the surrounding page can have some control over what's happening inside this frame, including an attempt to capture some of the information. It could be a possible exploit risk. Do keep in mind that OpenID providers are very paranoid about these things and might even attempt to break out from such an IFrame or just deny any further login actions. It's a risk that they might not want to take.
Is it possible? If it is, I think the answer also depends on the provider.