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.
Related
Update: Due to code refactor, the need for testing that has gone away, and as Ron pointed out in the accepted answer, onAuthStateChange() will fire eventually, and the app can rely on that. I wasn't originally seeing that, which is what motivated my question.
Original Question: I've been using window.localStorage and searching for a key that starts with 'firebase:authUser' as a way to determine if my app can expect a firebase authentication event any time soon. Whether it succeeds or fails, firebase.auth().onAuthStateChanged() is triggered, and I can deal with the result there. The reason for wanting to know is that if I have some local credentials which are being processed, my app can display a 'Please wait...' type message. But if there are none, it can redirect immediately to the login page. Since firebase moved to indexedDB, this code no longer works, and I couldn't find any equivalent hack to look for locally persisted credentials (maybe it's not possible now?).
I'd also be happy to switch to SESSION persistence rather than LOCAL, but I'm not sure if this changes the scenario at all—I'd still need a way to test if there was anything happening to avoid the user being stuck at the 'Please wait...' message forever if there were no local credentials to validate.
Or am I doing this wrong? I know I could show the login page until firebase.auth().onAuthStateChanged() fires, but by then the user might have clicked, and the experience isn't that great either if they already signed in and then refresh the page, where they see the login page again until everything is loaded.
I couldn't find anything in the auth() API to tell if it was in the process of dealing with locally persisted credentials, and up until now, the window.localStorage hack has been working very well. What's the best way to manage the user experience now?
You could grey out inputs and disable submit button until .onAuthStateChanged resolves which happens very quickly, usually in under 1 second. Maybe put a linear progress indicator on the login form?
Relying on underlying implementation is never a good idea instead of provided public API. Firebase has the right to change that at any time. They could have even persisted the user with a different format and that would break your implementation.
That said, you can easily bypass this, by setting your own flag in localStorage when a user logs in and remove it when they sign out. This is better than relying on the hack you had. In this case, you have full control over that flag. You set it anytime a user is signed in after onAuthStateChanged is triggered and remove it on sign out. When a page is loaded you read that value directly to know whether to display the progress bar or not.
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.
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.
Here's the question scenario:
Suppose you have a multiple-page ASP.NET web site with the following
requirements:
User-specific data for the currently logged in user is loaded and is required on each individual page of the application during a user's session.
The application itself only allows a certain number of users to be logged in at one time.
The next time a specific user logs in, the user should be returned to the last page visited.
Given this information, briefly describe how you would use ASP.NET to manage the state of the application to meet these needs?
Here's my thoughts and reasons. Please provide yours.
User-specific data for the currently
logged in user is loaded and is
required on each individual page of
the application during a user's
session.
This is suggesting to me that the interviewer is looking to see if I would suggest using Master pages as a way to provide a common approach to displaying the same thing on every page.
The application itself only allows a
certain number of users to be logged
in at one time.
Could the sought response be that, because scaling isn't an issue due to the limited number of users, that it is OK to put this information in the Session object for performance reasons or is this a trap and some of approach is better?
The next time a specific user logs in,
the user should be returned to the
last page visited
A cookie seems the best approach to track the last page access, since this doesn't seem to be critical information.
Please tell me how you would handle these question if you wanted to make the best impression
Feel free to provide input or comment an any line item.
Thanks!
As far as (3) is concerned, consider a shared PC. User A logs into a website using their site based user name/password. Does a whole load of work and shuts down the browser. USer B then comes along and on the same PC logs into the same site using their details. However, they will get the cookie from User A and be redirected to the last page they saw. This happens because Cookies are tied to the browser / OS user, where as you are potentially applying the site security separately in the application.
In this situation you would either need to put the user name into the cookie (encrypted) or use a server side method to store the location
Here are my thoughts:
They might be looking for Master Pages, but my first thought here was whether you're going to cache this user data, so you're not making a database query every time they hit a new page. To really impress them, you might mention partial caching techniques so that the repetitive portions of the page don't even need to be re-rendered with each page load.
I think you're right: they're helping you to conclude that the session state is an appropriate place to cache the user data. Just be sure you ask the appropriate questions, like "How many users?", and "How much data per user?"
The cached data could be used to keep track of the last-requested page, and when the user's session expires, you could save this data into a database table to be retrieved next time they log in.
That third item is awfully tricky. What if the user was last looking at an object that has since been deleted? What would be the intended behavior if a user logged in from one computer, did some work, and then logged in simultaneously from another computer or browser? I'd be sure to ask these kinds of questions, not least to show that I understand the implications of a requirement like this. If their responses lead you to believe that they're looking for a simple solution, go with the simple solution. Otherwise, tweak your response to be only as complicated as necessary.
Just a small thought.. If the system are running in a "Farmed" environment the Session data can be cleared and need to be handled some way.
http://www.beansoftware.com/ASP.NET-Tutorials/Store-Session-State-Server.aspx
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.