I have built two different user control libraries to use on my SharePoint 2007 site. One provides user controls for Ecommerce functions, the other for an account dashboard. Both of them are make use of authenticated users/site membership.
So I've built an assembly called WebAccounts.dll which contains all of the basic, common, account functionality such as logging in, logging out, retrieving member data and storing certain pieces of member data in session. Both the Ecommerce library and account dashboard library reference this account and build on top of it. For instance, both provide their own version of a login/logout control that captures the user credentials, and pass them along to WebAccounts to be authenticated and store the authenticated member object in session.
Where I'm lost is ultimately how IIS creates AppDomains and instances of these libraries. If I place all 3 assemblies in the bin of my SharePoint site, is a user guaranteed to be using instances of the three assemblies contained within the same AppDomain? Or on one page might a user's request process in an AppDomain where only Ecommerce and WebAccounts is loaded, and the next request process in an AppDomain where only dashboard and WebAccounts is loaded?
Point in case: I would like WebAccounts to provide Login and Logout events so that anything that uses the assemblies can perform server-side actions in response. I.E. Can a user be using Ecommerce, which adds some objects to Session State, then click "log out" on a Dashboard user control, which in turn calls Logout() in WebAccounts.dll, fire a "LoggedOut" event in WebAccounts.dll, and be guaranteed the instance of Ecommerce I was using (which has subscribed to the event on application startup) will be able to handle that event to remove its items from Session State? Another example is if WebAccounts defines a static variable, will Ecommerce and Dashboard use that same variable as I navigate between the pages of the site? Since these all run under the same application starting point, the SharePoint site, in the same bin together, it seems like they should all be in the same AppDomain and it should work?
Other concerns are the GAC, and scalability. First, my assemblies are actually in the GAC, because it's a lot easier to use them in SharePoint that way. My expectation would be that loading them from the GAC instead of the bin wouldn't change the way AppDomains are set up. Second, if we were to move to a server farm, could it still work. Given than we're using SQL based session state, I think that part would work. I know accessing a static variable would break down from request to request because there would be multiple instances of the variable on different servers, but could the variable be reliably set and retrieved by both user control libraries during a single request? Was my WebAccounts assembly just a horrible idea for a web site?
During normal operations there is one worker process and one app domain for each web site (assuming you are using one web site per app pool - I'm not aware of any reason of not doing that).
This means that all code that is loaded will share the same static variables and the same application state.
During recycling there can be multiple workers and multiple app domains but their contents are structured in the same way.
I don't know how Sharepoint operates. Probably, it runs as a single web site. Therefore, all code that is loaded is hosted in the same app domain.
The litmus test to see whether two libraries share the same app domain is whether they have access to the same HttpContext.Current.
The GAC does not play any role here. There is no such thing as "an instance of a DLL". There is just one DLL and it can be loaded into different app domains.
I know accessing a static variable would break down from request to request because there would be multiple instances of the variable on different servers
That is true.
but could the variable be reliably set and retrieved by both user control libraries during a single request
During a single request there is only ever one app domain involved in processing it. No exceptions. Whatever code is loaded in that app domain can take part. So as long as Sharepoint decides to load your code (and call it) you're set.
I would like WebAccounts to provide Login and Logout events so that anything that uses the assemblies can perform server-side actions in response.
The key question is: Is there anything that causes your DLLs to hook up those events? Ensure that that is the case. It is not a concern whether your DLLs are loaded or where. The concern is whether code in them is being called to allow them to subscribe to those events.
Related
I have a web application developed in asp.net
The application has a "logon" portal where I record users logging on. However, I don't really know when they have exited the web application as they could just shut down the browser, rather than using the "logout" option. As IIS keeps track of session variables for a finite period when users logon, I thought a really useful option would be to use my ASP.net application to interrogate IIS for the value of all session variables, thus telling me who is still active via their session variables.
This could be very useful when it comes to dropping in an upgrade to the website and generally looking at the use of the site.
Thanks
session object. But it only tells me about the current user.
I need complete information about how aspx single page server multiple users as compared to stand alone window application where separate exe is running on each user machine.But how exactly single aspx page serve multiple users at same time.
I search on Google but not get any good example.
I need any article or reference link for understanding the same.
Every request to any ASPX page will create a separate instance of the page class, generally all in the same AppDomain.
There is no concept of a "user", although you can create one using cookies or session state.
Choosing Between Windows Forms and Web Forms
Programming model
Windows Forms is based on a client-side, Win32 message-pump mode,
where instances of components are created, used, and discarded by the
developer.
Web Forms relies on a largely asynchronous, disconnected model, where
components are loosely coupled to the application front end.
Typically, application components are invoked through HTTP. This model
may not be suitable for applications requiring extreme throughput from
the user end or for those with high-volume transactions. Similarly,
Web Forms applications may not be suitable for database applications
that require high levels of concurrency control (for example,
pessimistic locking).
Security
Windows Forms uses permissions in its implementation of code access
security to protect computer resources and sensitive information. This
allows careful exposure of functionality, while retaining security.
For instance, the Printing Permission, which at one level would allow
printing to the default printer only, at another level would allow
printing to any printer. Using ClickOnce, developers can easily
configure which permissions their applications should and should not
demand from the client. For more information, see ClickOnce Deployment
and Security.
Authorization to gain access to the resources of a Web application is
typically controlled on a per-URL basis by authenticating the
credentials (for example, a name/password pair) of the requestor. Web
Forms allows the developer to control the identity under which server
application code is executed. Applications can execute code with the
identity of the requesting entity, which is known as impersonation.
Applications can also dynamically tailor content based on the
requestor's identity or role. For example, a manager could receive
access to a site, or a higher level of content than someone with lower
permissions.
I have several websites that use a HTTPModule (wrapped in a dll) to authenticate users and store an authentication object in the application cache for ~10 hours. I then set a cookie containing the cache key on the users machine.
I'm now looking for a way to allow admins to clear a specific cache object for all websites for any given user (effectively logging them out) causing them to automatically log back in (via windows authentication) next time they visit any of the sites.
I was planning to have a single administration website with the facility to reset logins - but I can't change the application cache for other websites for obvious security reasons.
Is there any way of passing a signal to those sites that use the authentication module so that they can clear their own application cache?
Note: I have read up on memcached but I would like to avoid a solution that isn't 'Standard ASP.NET' if possible.
Here are two ideas:
If they are on the same server, you could have a file containing the active logins in the file system, that all projects can access.
Add a generic handler to each project, that resets the login of a given user. Call this from another project when he gets logged out there. You could add a passphrase for security reasons.
EDIT: I just thought of a better solution:
Create a central "authentication" project that keeps track of the login status. Call it from the websites (e.g. through generic handlers, webservice, ...) to log out a user or check his status.
I've opted to piggyback code onto the existing HTTPModule.
I check for a custom user-agent string, if it exists I clear the relevant cache entries based on a query string and return a custom HTTP header upon success.
The only extra overhead is checking the user-agent for each request which I can live with.
With this setup I can now use a WebRequest object (injecting my custom user-agent string) from my central site to send messages to all sites using the module.
I am currently writing a user management application which administers users in a single aspnetdb instance. This single instance contains multiple "applications" which all have roles assigned against the individual applications.
As each user can be a member of multiple applications I use Roles.ApplicationName to cycle through each configured application and then determine which roles they are a member of. After checking each application I set the Roles.ApplicationName back to the original application which is the management application.
The problem I am having is when multiple users eachview an individual application and a request for Roles.GetAllRoles() is made. Most of the time the roles that come back are for the intended application but sometimes the wrong application's roles come back due to other requests cycling over the Roles.ApplicationName per application.
I've since read that Roles.ApplicationName is not threadsafe and therefore should not be used in a web application but I would prefer to have a solution to this rather than having to rewrite the role model in the application.
Also, The aspnetdb applications are created via this administration system and therefore I cannot create multiple RoleProviders, one per application.
Why dont you write a wrapper to do this, off the top of my head you could implement your own role provider, and then put the appropriate synchronization in place.
I'm building a solution where 2 applications are involved.
One of them handles the login and user management, and and other provides the service itself.
I need a way to send the user from the first app to the second, along with some data that derives from the whole login process.
The data has to be sent in such a way that it can't be tampered with; or a way to check if it's legit has to be available.
Some more details:
The solution consists of 2 ASP.NET (Webforms) websites
Although both websites are sitting on the same server, a solution that doesn't rely on this is prefered
Thanks in advance.
It might not be the best solution.
But this is what immediately comes to my mind.
Serialize the data, (from first website) that you need to pass, into a database accessible from both web sites (can be a third server in worst scenario when your both website might be sitting on different server).
Generate a key for the serialized data in the database. It can be a GUID. Pass it on to the other web site. Other website can delete it immediately after retrieving it by using the give key.
You could set an encrypted token cookie in the login application and pick it up in the management application.
I don't know of any way to transfer state data between applications on the server.
I am not if it is possible to use Server.transfer to the second site. But this would definitely be tamper-proof since it would occur on the server. The landing page on the second side would then persist the transfered info. Context object would be a good location to store the transfered info.
At a minimum it would recquire both apps to be on the same server.