If a user on my site said they were the Wikipedia user "example" what would be the best way of confirming they are indeed that Wikipedia user & not an imposter?
Ask them to put something on their user page, then check the history to see whether it was really them who put it there.
Wikipedia also supports OAuth, so you should be able to ask them to authenticate with OAuth to prove that they are who they say they are.
Don't forget to check the History tab to double check they were really the one making the comment
Related
A while ago I signed up for Read the Docs but I now no longer wish to use the service.
On my settings page, there seems to be no 'delete account' option and I cannot find anything in the documentation.
Is there a way to delete my RTD account?
At the moment, there seems to be no way to do this yourself.
There's an issue in the GitHub issue tracker about this, because others alredy had the same problem:
How to delete account on readthedocs.org?
The issue is full of "please delete my account" comments, and at least in the beginning, those accounts were actually deleted by hand. I think this is your best chance at the moment.
But they intend to make deleting accounts possible in the future.
Eric Holscher (one of the people behind Read the Docs) commented:
We aren't an evil corporation
that won't let you delete your accounts on purpose, just a lazy open source
project that hasn't implemented the feature yet :)
Just adding an update for anyone trying to solve it: there is now an option to do so. Log in, go to https://readthedocs.org/accounts/delete/, enter your username and you can delete your account.
What ways are used to show a user help the first time they use a page - to showcase certain features they might not realize are there.
For instance, say a search form is introduced that has a hidden "advanced search" option:
I would think most people would see the chevron and click it, but..you never know. I know that I could add a cookie to say "Hey - this user has seen it" or create a table in the database.
The problem I see with adding a cookie, is if the user deletes cookies and logs back in - they will have to always dismiss the alert/error/whatever. Unless after a period of time, I go in and manually delete it (which then new users wouldn't see the alert.)
Alternatively, adding a table to the database seems too much for such a simple task. It's what I'm leaning towards, but I hate it...there has to be a better way.
Are there any other ways to show a one time alert for certain pages?
Edit - I used a pretty trivial example on purpose.
I guess both your options are right. The cookie option is bit better cause it will be lighter on the server, again in case you have many users then the database options will be not great.
You may also lookup the new HTML5 feature of storing data on client side. Its a better local storage method.
It goes like localStorage.uid="1234" or something like clickcount.. Refer the html5 docs its a great feature as well.
Heres the link..
http://www.w3schools.com/html/html5_webstorage.asp
have fun..
I am building a robotlegs app where you have to login in order to use it. When you loggin I have numerous mediators,injectors,models,vos etc. What should I remove when one logs out?
Thanks in advance.
This is tough to answer, since your question is kind of vague. Some more details as to the inner structure would be helpful. Depending on your situation, you may just need to remove any navigation elements that would let the user access content that would require them to be logged in. If your user is represented by a persistent object, you could also use an isLoggedIn flag that you would check when the user tries doing something that requires them to be logged in. Again, this is tough to answer because of the question's vagueness, but I don't think there's anything really specific to RobotLegs you need to do, it's more about application design.
There is a onRemove function in the mediator which works like onRegister, it should remove all the registered events in your mediator. Have a look, it may be what you're looking for.
Stephen
In other words - what would be a good name for a variable that references the currently logged user?
I've come up with a few:
logged_user
visitor
me
I'm not convinced either of them is good enough though.
current_user seems the obvious choice.
The underlying point is worth some elaboration.
It is very important to choose good variable names, where a "good name" has the properties of being
accurate (not sloppily named)
concise (short as possible, without losing meaning)
unambiguous (not easily confused for something else)
If you are stuck then try to describe the thing in plain English.
Do you want to store the name of the user who is currently logged in? How about currentlyLoggedInUser?
In your context do you care about users not logged in?
If not then currentUser would do fine, and it's more concise.
Can it be confused for something else?
Nope. We have a winner!
Now you could shorten it further, like currUser but you lose some of the clarity. Remember the IDE will be there to help you type, so you have to think what you're losing (clarity) as a trade off from what you gain (fewer keystrokes). That point can be settled by personal taste when you're developing by and for yourself, but if you're in a team it's a no-brainer; choose the version that will be easiest to understand in future.
Think of that axe-wielding maniac who has to maintain your code in five years time.
Either theUserWhoLoggedInAFewMinutesBeforeAndWhoHasNotYetLoggedOutAgain or just ich
authenticatedUser, validUser, activeUser, authUser
I would be more inclined to go with the simplest form user. If you need to identify a previously logged on user then previousUser is a logical choice. Also, if you need to distinguish between a user that is logged in or not then a simple isUserLoggedIn boolean will do the trick.
loggedOnUser seems appropriate.
I think currentUser OR loggedInUser seems better.
I'm specifically thinking about the BugMeNot service, which provides user name and password combos to a good number of sites. Now, I realize that pay-for-content sites might be worried about this (and I would suspect that most watch for shared accounts), but how about other sites? Should administrators be on the lookout for these accounts? Should web developers do anything differently to take them into account (and perhaps prevent their use)?
I think it depends on the aim of your site. If usage analytics are all-important, then this is something you'd have to watch out for. If advertising is your only revenue stream, then does it really matter which username someone uses?
Probably the best way to discourage use of bugmenot accounts is to make it worthwhile to have an actual account. E.g.: No one would use that here, since we all want rep and a profile, or if you're sending out useful emails, people want to receive them.
Ask yourself the question "Why do we require users to register to access my site?" Once you have business reason for this requirement, then you can try to work out what the effect of having some part of that bypassed by suspect account information.
Work on the basis that at least 10 to 15 percent of account information will be rubbish - and if people using the site can't see any benefit to them personally for registering, and if the registration process is even remotely tedious or an imposition, then accept that you will be either driving more potential visitors away, or increasing your "crap to useful information" ratio.
Not make registration mandatory to read something? i.e. Ask people to register when you are providing some functionality for them that 'saves' some settings, data, etc. I would imagine site like stackoverflow gets less fake registrations (reading questions doesn't require an account) than say New York Times, where you need to have an account to read articles.
If that is not upto your control, you may consider removing dormant accounts. i.e. Removing accounts after a certain amount of inactivity.
That entirely depends.
Most sites that find themselves listed in bugmenot.com tend to be the ones that require registration for in order to access otherwise-free content.
If registration is required in order to interact with the site (ie, add comments/posts/etc), then chances are most people would rather create their own account than use one that has been made public.
So before considering whether to do things like automatically check bugmenot - think about whether their are problems with your business model.
There are a few situations where pay-to-access content sites (I'm thinking things like, ahem, 'adult' sites) end up with a few user accounts being published publically (usually because someone has brute-forced some account details), and in that case there may be a argument for putting significant effort into it.
From an administrator viewpoint absolutely. That registration is required for a reason, even if it's something just as simple as user tracking/profile maintaining. Several thousand people using that login entirely defeats the purpose. IP tracking could help mitigate this problem, but it would definitely be hard to eliminate entirely.
No need to worry about BugMeNot: http://www.bugmenot.com/report.php
With bugmenot, keep in mind that this service is not actually there to harm the sites, but rather to make using them easier. You can request to block your site if it is pay-per-view, community-based (i.e. a forum or Wiki) or the account includes sensible information (like banking). This means in virtually all situations where you would think that bugmenot is a bad thing, bugmenot does not want to be used. So maybe things are not as bad as you might think.