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.
Related
How to restrict the page by accessing only one user at a time. Using asp.net can i use global.asax, is there any other way to restrict, if one user accessing the page, another user not able to access that page. we have to give message that one user is accessing the page. is it possible. can you help me or give some reference.
Although there are probably many better ways of dealing with this sort of problem, I'm going to assume that you do actually need this.
What I would do:
Make your application so that when the page is loaded(when it isn't "locked"), it logs to a database that the page was loaded and "lock" it. In the actual page, I'd have some kind of AJAX to constantly poll the web server every 5-15 seconds to tell your application the user is still on the page. And then make it so that the page becomes unlocked after 5-15 seconds from the time saved to the database by the last AJAX call.
Again, I really suspect that there is a better way around an issue like this, but this is a direct answer to your question
Based on this:
yeah sure, jupaol, it is depend on accounts, in my web application, one report has to approve only one user, but the approve authority having two users. if both of them accessing the same page and approve at a time, it will big mess. here i an not using database.
The problem is related with concurrency, there are several ways to face an issue like this, for example the easiest one is to use optimistic concurrency. Even when you are not using a database for this, you can emulate it.
You should be storing the result of the approvers somewhere, in order to mark the report as approved, with this in mind you should be able to do something like this:
Before render the page get the latest report status
If the report has not been approved, render normally
If the report was approved seconds before, render it in read-only mode reporting who approved it (or similar approach)
Add a validation to your ChangeStatus method, in this method do the following:
Get the latest status of the current report
If the report is still not validated, then block the thread (you could use a Mutex or similar) and mark the report as validate it
If the report was already validate it, raise a domain exception and handle it in your page correctly (perhaps render the page in read-only mode explaining that the report was already validate it)
If you want a more responsive application, (RIA), you might want to consider the following approaches:
Perhaps this would be the worst approach but it's still an option, you could keep a log tracking when a user request your page, then in subsequent requests check if the log is still valid, if it is not, then redirect to another page indicating the page is in use, otherwise allow access to the page. I believe this is an error-prone approach because you would be relying on this simple validation in order to prevent an inconsistency in your system, besides you would have the polling problem described in the following approach
Using AJAX to poll data from a service checking if the report has been approved. Perhaps this is the easiest way to accomplish this but it is not recommended it, because you would be polling your server constantly, and eventually you would have scalability problems
You could use Comet to get notified to the browser (client) whenever a server event has occurred, in this case when your report has been approved. The problem with this approach is that you have to keep an opened connection with the server in order to get notified.
The last approach and the most recommended these days is to use Web Sockets, this is the technology used in StackOverflow to get notifications in real time.
The reason I'm asking is because, right now we already have it setup to prompt users to share things if they're connected. But the biggest problem we have is that without the user being connected, it tries to make a popup window — which is blocked in most browsers. (vs. the iframe inline)
So, I'm trying to see what the benefit or difference in us implementing the new changes if we're already doing "timeline-like" sharing. I don't get it? Do we have to recode everything?
Last, off topic, but I'm confused about the way the referral API works actually, because the same code doesn't seem to invoke the API at all. Just display the user's name
You need to get the users "publish_actions" permission to add things to timeline. So in that sense, yes, they do need to be connected. But the advantage of that is that once you get "publish_actions" permission, the user never needs to be prompted... you just automatically share the actions they've taken by making api calls.
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..
I was wondering if it is even possible to interact with other websites using my own.
Here is the scenario:
Lets say I have a Lockerz account, which is a place where you do daily tasks to earn points. Once a month you can redeem those points to get prizes such as an ipod, macbook, or other items. I know that sounds rediculous, but stay with me.
For someone to gain membership to this website they must be invited by a member. So I get your email address then log in to my account, then send you an invite from there.
What I want to do is create a website where a user enters their email into a textbox and presses a submit button. From there the program, behind the scenes, sends my login information, and the users email address to lockerz and sends the invite. All without ever leaving my site.
I have worked with ASP.NET with VB codebehind for a while now, so I understand the basics of that. I am just wondering if what i want to do is even possible. If so, can someone redirect me to a tutorial or guide of some kind that will give me a basic knowledge on this.
Thanks
You'll have to work down at the HTTP level, sending POST and GET requests.
Fortunately, .NET has the WebRequest and WebClient classes to help you.
WebClient would probably be your best starting point... But I would hang on a second.
Websites like this tend to employ some pretty intense fraud-protection. Banning, blocking or at least ignoring actions when multiple accounts use one IP, or otherwise do things in a predictable pattern.
WebClient isn't going to load up the JavaScript either so you might you can't access required parts of the page.
Either way, you don't need to do this on your webserver - I'd start off by writing it initial connect code locally as a simple script. It'll make testing it a lot faster.
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.