I want to enable an user to be able to communicate with other users through a site. I know that ASP.net is stateless, but what can I use for this synced communication? Java servlets?
I don't think you need to set up Java just to use a servlet for this. I would use AJAX and the database. I don't know ASP.NET but I PHP is similar in this case, being also basically "stateless". If you want to display some kind of asynchronous communication between two different users, say, from two different sessions, without a lot of refreshing (like chat), you can have the AJAX page constantly poll the database for new messages, and display them when they come in. You can also use AJAX to insert the new messages, giving the user read/write access to this messages data structure. Since the "other" user is doing the same thing, user A should see new messages pop up when user B types them in.
Is that what you mean?
You probably don't want to use sessions for things like chat messages but you probably could use some type of implementation of queueing using MSMQ.
The approach to chat could be done in many different ways, this is just a suggesting off the top of my head.
Could do a messaging solution in Java Servlets using the application context. Objects stored as attributes in the application context are visible from anywhere in your webapp.
Update: Chat like functionality... I guess that would be AJAX polling your message structure stored in the app context unless you want to use something like applets.
Don't know if it's any good, but there's a chat servlet here that might be useful to use or learn from if you decide to go the Java route...
ASP.NET is "stateless" but it maintains state using Sessions. You can use them by default just using the Session[] keyword.
Look at ASP.NET Session State for some details from Microsoft.
Related
I'm trying to build a web app that lets a user create a session which generates a unique session ID through which other users can join the session and post messages on a board. However, I am stuck at real-time updates for the specific sessions as I am unaware of technologies that allow me to accomplish this task. I've read about .NET's SignalR as a real-time web app API but so far have not found a way to handle each session separately. I am looking for recommendations and preferably tutorials on how to implement this feature.
The Web API is built in Spring Boot and .NET, so I would prefer APIs/tutorials for these frameworks. Thank you.
Just thinking of the easiest way to do this with minimal strain on the server. I think I would go down the road of storing the session IDs in the db and then use ajax to handle the realtime updates. Ajax can run on a js timing loop that can check a serverside flag which is set once updates are made to the db. Upon finding a set flag the ajax can then pull in the updates or do a page refresh.
I really need some expert help here!. Does anybody knows of a way of getting the list of the users currently connected to a BlazeDS server? Is there any built-in mechanism of knowing this? or do I have to implement some kind of server side logic every time a user access my Flex application and store all logged in users details somewhere and retrieve them later?
The nearest thing I can think of, using BlazeDS, is to obtain a list of clients currently subscribed to a destination, but this won't solve the problem IMO.
First of all, you need to define a destination and make sure that all clients will actually subscribe to it (see BlazeDS documentation for this). Then, on the server, you can then get a reference to the message service
MessageService messageService;
messageService = (MessageService) messageBroker.getService("message-service");
and ask for all subscribers with the getSubscribersIds method on the MessageService instance, specifying the name of your destination. This will only returns a number of identifiers, internally generated by BlazeDS (they are also available on the client side of the connection).
To resolve the same problem, I used this approach in combination to a custom server-side logic to store logged-in users (explicitly invoked login/logout methods). Regularly looking at the subscribers can help to clean this store, because in my experience there's no way to be sure that a "logout" method will always successfully called, expecially from Flex client running in the browser, while BlazeDS will automatically take care of cleanup of the subscribers.
I don't like very much this approach, probably someone came up with a better solution..
Using a trigger-based approach to audit logging, I am recording the history of changes made to tables in the database. The approach I'm using (with a static sql server login) to record which user made the change involves running a stored procedure at the outset of each database connection. The triggers use this username when recording the audit rows. (The triggers are provided by the product OmniAudit.)
However, the ASP.NET Membership tables are accessed primarily through the Membership API. I need to pass in the current user's identity when the Membership API opens its database connection. I tried subclassing MembershipProvider but I cannot access the underlying database connection.
It seems like this would be a common problem. Does anyone know of any hooks we can access when the ASP.NET Membership makes its database connection?
Update 2:
Not looking good on the AOP front, I am afraid - see Is is possible to intercept a static method on an object you don't own and did not create?
And as alluded to in comments, it looks like the best bet is to use the Provider Toolkit's implementation of the providers and wire your hook into SqlConnectionHelper.GetConnection()
I use the toolkit code, which I have cleaned up considerably, reliably for years with no problems. Let me confirm on 4.0 and package it up if you are interested.
Update:
Ok, I think I better understand your need, tell me if I am correct:
You need the actual connection that is being used by the provider?
SqlMembershipProvider utilizes a helper class, System.Web.DataAccess.SqlConnectionHolder, for all of it's data access.
I have not done this, but from what I have gathered, you could intercept calls to build this object using an AOP implementation such as Castle DynamicProxy (or one of the libraries that leverage it) and get your connection there.
Could some one with more experience confirm or deny this?
Original answer:
No need to derive from SqlMembershipProvider. Just go in and get what you need.
string connectionString =
typeof(SqlMembershipProvider)
.GetField("_sqlConnectionString",BindingFlags.NonPublic | BindingFlags.Instance)
.GetValue(Membership.Provider);
I am using DotNetOpenAuth in my ASP.Net Website. I have modified it to work with Facebook Connect as well, using the same methods and database structures. Now I have come across a problem.
I have added a Facebook Connect button to a login page. From that HTML button, I have to somehow pull information from the Facebook Connect connection and pass it into a method to authenticate the user. The way I am currently doing this is by:
Calling a Javascript Function on the onlogin function of the FBML/HTML Facebook Connect button.
The javascript function calls a Web service to login, which it does correctly.
The web service calls my data access layer to login.
And here is the problem: FormsAuthentication.SetAuthCookie is set at the data access layer. The Cookie is beyond the scope of the user's page and therefore is not set in the browser.
This means that the user is authenticated, but the user's browser is never notified.
So, I need to figure out if this is a bad way of doing what I need or if there is a better way to accomplish what I need. I am just not sure and have been trying to find answers for hours. Any help you have would be great.
Yes, it sounds like you are having a design crisis brought on by trying to do too much at one time/in one place.
If you break this operation up in to two calls from the client you will find your options opening up quite a bit. It might take some more work but ultimately the code will be less complex. <-- a good thing.
And in my opinion, the first clue pointing to a crisis of design would be when I said to myself "Self, having an authentication method buried two calls deep in my DAL is not working the way I would like...." lol.... I am joking and serious same time.
Good luck.
I'm building UI logging into a long-existing ASP.NET enterprise application. I have my own ideas of how to progress from here and am continuing to research & design. But I'd love to hear some details from the SO community.
Here are the details, assumptions and questions as of right now, subject to evolve within the enterprise as well as whatever input comes in here on SO:
Would prefer to have a consistent DB connection since there will be a lot of activity
Will probably use the ThreadPool, but will this conflict too much with ASP.NET vying for threads?
Possibly use in-memory queue (Queue) for logging batches of inputs periodically? (one per domain)
Will need to be configurable. IE: Could log all page events during their normal postback calls, or hook individual control actions or events to being logged whether there's a postback or not. IE: User collapses a panel.
All "high-visibility" UI events that'll already be posting back as well as other events that won't necessarilly post back right away. Have a client batch of events and send occasionally?
How do we minimize the impact on existing code?
Have "fly on the wall" AJAX functionality that posts back accordingly? It'll basically be watching all that's been configured to be logged.
Logging must be ordered for reporting a user's step-by-step progress from point A to B in a workflow.
How about a WCF service that does the actual logging, paired with a PostSharp attribute. In your PostSharp attribute you can call asynchronously to you WCF service while your application hums along. I've implemented something like this in past projects and it works great with little if no slowing down.
http://www.postsharp.org/
Why not use log4net? You could capture a userid, sessionid, and any additional information you need to track step-by-step progress. You could configure the levels so that you could reduce the logging if it impacted performance. I wouldn't consider re-inventing the wheel by writing your own framework when there are several viable existing logging frameworks.