In a certain situation, I want a request to execute as a user different than the one actually logged in. So, when User A requests a particular page, from code I want to switch it execute under the user account of User B -- only for this single request (or even for a single block of code...)
I've used this:
FormsAuthentication.SetAuthCookie("UserB")
This works, but it's persistent. When I request a new page, I'm now logged in as User B, which is not what I want.
Is this possible? I've RTFM'd up and down for this.
Edit: I may have found an answer, which I posted below. Looking for confirmation or refutation of this solution.
I think I might have found it. I'm not 100% sure, but this works. I just don't know if it's completely correct or if there's something I'm not considering.
HttpContext.Current.User = PrincipalInfo.CreatePrincipal("UserB");
Again, this seems to do what I originally wanted. If you have experience that would prove me right or wrong, please comment.
Related
I find that some websites have sort of authentication even though no user is logged in. Taking plunker for example, even a non-logged in user can freeze a snippet such that other users cannot modify; whereas the user himself could always modify the snippet even though he opens the link in another browser tab.
My current solution is adding a type field (ie, anonym and normal) in the user model. Then, each time there is no normal user logged in, I systematically generate a unique random ID, register and login as an anonym user. It works, but the shortcoming is there are lots of anonym users in my database.
Does anyone have a better solution? Is there any "standard" way to realize this kind of hidden authentication?
I think method you are looking for is called session id. When you save as anonymous user web app creates a session with a session id which is used to identify the user by link. For example on plnkr it'll be something like https://plnkr.co/edit/session_id?p=catalogue where session_id is some sort of hash.
To freeze the snippet the session id is written into cookies with the flag, saying, for example, that the state is frozen. If you freeze it in Chrome and open in a Chrome's private window or in Firefox on the same computer, you wouldn't be able to unfreeze it. It'll behave the same way as for other users which have no cookies. In fact using session hash for cookies, rather than any user identification is better for security reasons.
Now this approach in a sense isn't any better, than creating anonymous users - you still have to save session records into the database to be able to open session context by link. In fact, it might happen to be simpler in your case to do exactly what you did if user is assumed to be present in lots of use cases and places in the code.
In many cases, however, separation of session from user makes lots of sense as it simplifies keeping session state after login or registration. Say some web stores would empty your basket after you register, causing quite a bit of frustration, especially if you put several small items into it which you now have to find again and put back. Those don't have sessions or don't use them correctly on registration or login.
Otherwise, as I wrote it's pretty much the same and you have to deal with many anonymous sessions which pollute the database unless you have some sort of wise retention policy, depending on you use case. Say, for example, a web site similar to plnkr.co which is used to share code snippets, and post them on sites such as stackoverflow should better keep those sessions while there are users accessing those say at least once a year. So sessions should have access date and policy would be that it's older than 1 year.
Hope it helps.
I have done similar using Local Storage. It allows you to store data on the browser. A user can then open tabs, close browser completely and reopen etc and the data is still there. It would then appear to be saved for them but actually it's just stored on their browser.
This wouldn't allow others to see what they have done though, so not sure if this is quite what you're after.
I wrapped them in functions in case I chose to change them out later, something like this
StoreLocalVariable: function (key, value) {
localStorage.setItem(key, value);
},
GetLocalVariable: function (key) {
return localStorage.getItem(key);
},
Some info including compatibility
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API
I'm confused by the way that Mixpanel alias() is supposed to work, despite the fact that Mixpanel have multiple pages attempting to explain it.
According to this page, I should call alias() only once per user, because it will create a one-time mapping from their user ID to the device's generated ID. But shouldn't that mapping be the other way around? Let's say Bob starts my app on his phone and logs in, at which point I call alias() to map all his actions so far to his account. He then goes through the same process on his tablet - I would expect that I can then call alias() on that machine to do the same thing. But the page I mentioned specifically says not to do that, because it will map his user ID to that device's ID now.
I can call identify() on the multiple devices, but that does not link his previous events to his user ID.
I feel like I'm misunderstanding how this whole thing works, but I've now spent a few hours pondering this so I'm hoping it's confused someone else in the past too...
I always understood alias() as mapping the identifiers both ways. I've had a similar case as you. I'm almost sure that it does not matter how many times you alias and in which direction you alias the identifiers.
This is not authoritative though, but rather based on past usage and possibly-flawed understanding.
As they explain on their help documentation:
https://mixpanel.com/help/questions/articles/how-should-i-handle-my-user-identity-with-the-mixpanel-javascript-library
Ideal implementation
The ideal integration that will allow you to track users from anonymous browsing all the way through signup and subsequent logins:
When a new user signs up, call (once)
mixpanel.alias("YOUR_USER_ID")
When a user logs in, call
mixpanel.identify("YOUR_USER_ID")
Applying this to your question, you need to use identify when the user do login with the mobile and another time when he do it with the tablet.
I am curious about the value of PHPSESSID because, I created a simple login-type web app. When I try to login with different accounts, the value of the PHPSESSID is not changing. I got curious if it does okay or not. Because I tried to login in youtube with different account too. But their SID's differ on each user.
My question is:
1) Is what happening on my web app okay ?
2) Is yes, how can I make a session ids per account/user ?
3) If no, how can I fix it ?
I would really appreciate your suggestions.
It partly depends on exactly how you implemented "login." One way to do it is simply to change the user-identity (which, by definition, is part of the data that is stored in the session), while keeping the same session.
Another equally-valid way to do it is to first update the existing session (to show that the user, in that session, is now "logged off") (maybe...), and then to coin a completely new session-id, thus starting an entirely new session, in which you now "log on."
One advantage of the second approach ... and probably the reason why so many sites do it this way ... has to do with the possibility that the user might wish to open a new browser-window, and to log-in to the application a second time, intending to keep both logins alive at the same time. If the session-id token is part of the URL, or maybe is part of a hidden form or what-have-you, such that both session-id's can be retained independently, it becomes possible for the user to do what he has done without conflict. Two parallel sessions exist. In one, he is logged on as "joe," and in the second, he is logged on as "jeff." And so on. One set of browser-windows (somehow ...) carries the "jeff session" token; others carry the "joe session" token.
Fundamentally, a "session" is just a pool of server-side values, identified by the (PHPSESSID ...) token furnished each time by the client. Exactly how you choose to manage it, is at your discretion. It's a design-decision with no "correct" approach.
I request Google Places API once a week to see if my requests to add new places have passed the moderation queue (if the scope has changed to google).
The problem is that I don't know how to know if a request has been rejected by the moderation.
The only solution seems to ask for get-current-place (or other "search" request) and look for the place, since the place must not appear in the result once rejected by the moderation, but I'm not really convinced by that solution.
Thanks
Unfortunately there isn't a good or stable way to do this at the moment. Looking at search results gives an approximation, but there are other reasons that a valid place may not appear in the results, so it won't give a strong confirmation.
How we can implement Two recaptcha user control on the same page.
Problem :
we have two views one for tell a friend about the site by sending e-mail and another authoring any note. the tell a friend part is hidden which send e-mail through ajax and note author part is visible so it is making problem when we need both but in different way.
Refactor to avoid usability issue
This doesn't seem reasonable and I would suggest to avoid this at all costs, because you have a serious usability issue if you do need two of them. Why would you need two captchas anyway? The main idea behind a captcha is that it assures that there was a person entering data in the form and not a computer.
So if there's one captcha on the page, you're assured. So if the first one was filled by a person, all other data is as well and you don't need a second one.
But I can see one scenario where two captchas could come into place. And that's when you'd have two <form> elements on the page. So a user can either submit one or the other. In this case user will always submit data from just one form and not both. So you could avoid this as well by either:
separating these two forms into two pages/views with an additional pre-condition page where a user would select one of the two forms
hiding captcha at first, but when a user starts entering data into one of the forms you could move the hidden DIV with captcha inside the form and display it. This way there would only be one captcha on the page and it would be on the form that the user is about to send
The second one is the one you'd want to avoid. If you give us more details what your business problem is, we could give you a much better answer.
Alternatives
Since you described your actual business problem I suggest you take a look at the honey pot trick, that is more frequently used for this kind of scenarios. Because if you used too many captchas on your site, people would get annoyed. They are tedious work, that's for sure. Honey pot trick may help you avoid these unnecessary data entering.
The other question is of course: Are your users logged in when they have these actions available? Especially the editing one. If they are, you can better mitigate this problem. You could set a time limit per user for sending out messages. Like few per minute. That's what a person would do. And of course store the information about sending out these emails, so you can still keep historical track of what users did so you can disable accounts of this gets abused. But when users are logged in they normally don't have to enter captchas since they've already identified themselves during authentication phase.
The ultimate question is of course: Why would a bot send out emails to friends? they wouldn't be able to send any kind of spam would they? What's the point then? It's more likely that bots will abuse your system if they can spam users anyhow. Either by sending email with content or leaving spam comments on your site. These forms need to be bot checked.