Bypass Login Screen in Drupal 7 through a special URL - authentication

I am into a strange fix with my site.
Firstly, my site is password protected. So, when I visit, http://www.mysite.com it is greeted with a nice shiny login page. User puts in the credentials and goes in.
Now, I am hoping that for some special people, they don't have to login. For that I need to have some specific URL, say, http://www.mysite.com/bypass which takes me to the site without any login page.
Is it possible?
Many Thanks

It should be possible, but I wouldn't recommend it. A good option would be to just tell those special people to have their browser save the password.
To actually implement what you want - to log in without login credentials you'd have to do something like what "drush user-login" does. It creates a one-time link that allows anyone to become "logged in". It's the same functionality as the password reset link. You could probably detect the (type of) link and re-route it to the http://www.mysite.com/bypass address.
In the end it's best just not to do it.

Related

detecting link checkers (spam filter) in incoming HTTP requests

We have a site that uses a "one-time" login process for password resets which are not initiated by the user themselves. (for instance, a password reset that is initiated by an admin or another employee) A URL is sent to the user via email which can then be used to reset their password. The URL can only be visited one time. (there's more to this for security-sake but I'll keep it simple) Recently, some users have complained that when they visit the link, it has already expired. The end result is that they can't reset their passwords using this feature. We discovered that the users in question have a spam filter or "link checker" in their environment that they do not have access to. This device visits the one-time link before the user is able to, to make sure its safe.
I'm trying to solve this issue and was wondering if there's a way I can detect these type of devices on the web server when the request is made? When the spam filter visits the link, is there something in the http request that would stand apart from a regular browser? Maybe they all use a specific custom HTTP header? Or maybe there's a regex I could use on the user agent? I haven't been able to catch one of these yet, so I'm not sure what the request looks like coming from a spam filter.
Anyone know of a way to detect spam filters of any vendor by looking at the http requests? I know it's a long shot but maybe they all use a specific header for reasons such as this?
I got approval to modify the design to remove the one-time aspect of the URL. This solves the issue and saves me the headache. Thanks for the suggestion, #PeeHaa

Multiple users logged in Dropbox

I need to log in a user into Dropbox using Core API. Then remember his/her access token and allow logging in with another credentials (looks like a second Dropbox user). But when I make request to https://www.dropbox.com/1/oauth2/authorize it automatically ends up with redirect page with first user's access token giving no chance to enter another credentials. I know I can revoke first access token but then I will not be able to silently come back to first user.
Does anyone know is the possible to implement?
You can set the force_reapprove parameter for the /authorize page to true to prevent the automatic redirect:
https://www.dropbox.com/developers/core/docs#oa2-authorize
Note that the /authorize page is hosted on www.dropbox.com though, so the user will get their www.dropbox.com session, even if force_reapprove=true is set. With that parameter set though, the user has the opportunity to switch accounts, using the dropdown in the upper right of the page, before authorizing the app.
If that's not sufficient for whatever reason, you can try to end the user's www.dropbox.com. The simplest way is to direct them to www.dropbox.com/logout first. Be sure to make it clear to the user what is happening though.
Or, if you control the entire browser, e.g., if it's an embedded web view in your app, you can clear the browser's cookies, which will clear the session, forcing users to log in again.

Prepopulate Username and Password in Login screen

I have designed a standard login screen in ASP.NET like below:
As usual when operator selects “Remember me”, we expect system to not ask operator for credentials anymore and go directly to default (home) page.
My business team saw something on internet and they believe that when “Remember me” has been selected we need to pre populate the username and password and wait for customer to press “LOG IN” button:
I haven’t seen this practice so often and I am not very comfortable to do it. Although, I don’t have a good technical argument to explain and change their mind.
I am basically looking for good argument to explain cons and pros of above scenario.
Never ever should you pre-populate a passwords edit field. If you do so, everybody is able to read the plain-text password, if he can open the login form on this computer. A few minutes on an unlocked office computer would be enough to check the browser history, afterwards the attacker can login whenever and whereever he wants.
If you have a remember me function, and the user has logged in using this function, then there is no need to display the login form at all. You can just display the content. In this case, an attacker can do things with the account, but he cannot login unnoticed later from somwhere else.
I think (hope) you saw the pre-populated password field, because the browser filled in the content, and not the website did it. Maybe there is a password manager installed.

Checking whether a user is logged into Flattr?

Is there a way to test whether a user is logged into Flattr?
The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass. However, unlike a paywall, the user is not forced to click a flattr button; I just want to make sure that he's ready to flattr anything if he/she likes what he/she sees. I am not interested in his/her account credentials either.
Obviously, this is a thinly veiled scheme to get users to sign up to Flattr. I don't know whether this is a good or bad idea, but it might be worth a shot.
"The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass."
Beware that, if I remember correctly, it was not accepted in the Flattr code of conduct. Maybe it has changed lately (I cannot find the reference of this) but check first with some Flattr people if you can legally do that.
You can use "login" to your site with the Flattr OAUTH 2 API.
So what you would do is to connect your site as an third part application to flattr and then let the users authenticate with their Flattr login
http://developers.flattr.net/v2/#authorization
The first time the users access use your site they have to allow your app access to their Flattr profile.
Moreover, you can authorize a user without gaining access to any non-public features. To get any special access you need to specify the scopes for which you want special access - specify no scopes and the only thing you get to know is that a specific user has a specific account on Flattr.com.

twitter share url forgeting the tweet content after login

I'm trying to add a "share via twitter" link to our website. I'm aware of the standard http://twitter.com/home?status=TWEET method, and it works good enough for my purposes when the user is logged in to twitter already.
If, however, the user is not logged in, twitter displays the login form first (which is only reasonable). After the login, the home screen is displayed without the tweet content.
Am I missing something obvious, or is this a know flaw in this method? If so, what is the easiest way (apart from using services like TweetMeme, which I noticed asks for login in advance) to make the share button work as expected?
If the user is not signed in when accessing http://twitter.com/home?status=TWEET it seems that the status is indeed forgotten. This would be a Twitter website issue and not something you're doing wrong.
Update: Use this URL instead: http://twitter.com/intent/tweet?text=TWEET
TweetMeme, on the other hand, uses its own Twitter "application" via the OAuth authentication, requiring users to log in before retweeting using TweetMeme, and is smart enough to include the tweet message in the OAuth callback URL so that it's not forgotten.
So really, you can:
Use TweetMeme, where the user would have to log in, but at least have the tweet be remembered once that's done;
Create your own Twitter application that uses the same tweeting functionality as TweetMeme; or
Use Twitter.com's less-than-desirable status updater and hope the user is logged in, or hope that they're smart enough to click the back button a couple times and click on your link again if needed.
Just use the following url and parameters
http://twitter.com/share?text=YOUR-TEXT&url=YOUR-URL
Then it works.