Situation:
Users can access their google docs by an external link on a website. Now they first have to login to view their documents.
Problem:
I want that the users automaticly login on Google Docs
I've the username and password stored in a dabasase..
What is the best way to solve this problem?
There is no good way to solve this. You could fake a login programmatically, but that would work only to fetch a document, not to really log in the client. Plus it's really not a good idea to have a database with peoples' Google logins lying around, especially seeing as the passwords have to be unencrypted.
I would leave it up to the user to store their Google password in the local browser.
Related
Is there a way to find out which user is still online? I read somewhere that I cannot do that directly, but use the sessions to check either anyone is online. If it possible to get user sessions without having to know user credentials?
Or is that is an alternative way that i can do to get find out which users are still online?
Let me start by saying I really like Deployd. I want to use it in production, but I want to incorporate OAuth and social logins, so I installed the dpd-passport module. It works great, except for two little (big) problems:
When a user signs in via an OAuth provider (e.g. Facebook, Twitter, Github) a new user record is created...but if the same user clears their cookies or uses a different browser to log in, a new user record is created.
If I do something clever (read: hacky) and assign users with social logins an ID based on the socialAccount and socialAccountId (something unique but constant for each social account), someone could use the standard method of user creation to spoof a user by making a POST request to the /users endpoint if they knew that user's socialAccount and socialAccountId.
My question is: How can I A) prevent #1 from occurring, or B) disable the standard method of user creation without also preventing OAuth user creation?
Has anyone ever successfully used Deployd and dpd-passport in production? If so, I want to speak with you...
Thanks in advance!
First of all, I think you haven't added the custom fields per the docs.
https://www.npmjs.com/package/dpd-passport#requirements
I hadn't either, and observed the new user feature (because it couldn't lookup the response from the auth service to find the user from before). Adding these fields fixed it.
Also, there is a google group here:
https://groups.google.com/forum/#!forum/deployd-users
Hope that helps.
Here's my scenario - I have the credentials for a couple of websites that need username and password to login. I would like to programmatically do this but just don't where to strrt.
For example, say the website is www.mywebsite.com and the the U: UserID and P: admin.
I am thinking something like this (this is of course pseudo-code): open("www.mywebsite?username=UserID,password=admin".
Can someone lead me down a path where I could learn more on how to do this?
Thanks.
This is note a solution, but when I need to analyze a site I plan to scrape data off that requires a login, I usually use Fiddler to record my session. It will show you all the data between your browser and the site, so you can build the exact URL and variables needed to login to protected sites.
I have been tasked with creating a SharePoint 2007 webpart that logs the user directly into our website (which uses forms authentication). Most likely the username and password will be same in the SharePoint account as in our website.
Ideally we would like it to be fully integrated in that the webpart looks up the SP login & password, somehow encodes that using SHA1, MD5 or similar encryption, then passes that along to our login page on the query string. However given we have little experience with SharePoint, and that it's probably impossible to programmatically access the SP username/password from a webpart we realize this isn't very likely to be possible and if so would probably require a lot of development time.
Another option would be to load a login form from the website within an iframe in the webpart, which would show the login & password first but store a "remember me" cookie after the first login, and on each subsequent load display just a button that logs them in directly using the cookie.
Has anyone done something similar before? I'm in over my head, any guidance would be much appreciated! :)
A good login system doesn't allow retrieval of passwords at all. (Forgot your password? Prove you're you and we'll reset it, send it to you, and force you to change it to something we can't see once you're back.) This way you CYA against both Angry IT Admin Guy back-dooring his way into other user accounts when he's disgruntled over coffee pot politics as well as a potential attack vector for the Internet at large to exploit.
The cookie idea is plausible. Depending on your SharePoint/other website configuration you may be able to federate your logins to a single authentication provider (using ADFS, Passport, OpenID, etc.), which would be a more elegant solution, but may not be feasible in your scenario.
If you're using SPS 2010 and your other website is based on .NET, then Windows Identity Foundation would be a option.
I wish there was a central, fully customizable, open source, universal login system that allowed you to login and manage all of your online accounts (maybe there is?)...
I just found RPXNow today after starting to build a Sinatra app to login to Google, Facebook, Twitter, Amazon, OpenID, and EventBrite, and it looks like it might save some time.
But I keep wondering, not being an authentication guru, why couldn't I just have a sleek login page saying "Enter username and password, and check your login service", and then in the background either scrape the login page from say EventBrite and programmatically submit the form with Mechanize, or use an API if there was one? It would be so much cleaner and such a better user experience if they didn't have to go through popups and redirects and they could use any previously existing accounts.
My question is:
What are the reasons why I shouldn't do something like that?
I don't know much about the serious details of cookies/sessions/security, so if you could be descriptive or point me to some helpful links that would be awesome. Thanks!
Edit:
I'm familiar with OpenID and the APIs. I was really wondering about the security/legal/confidentiality side of things. I understand the confidentiality part totally, don't know if there's anything legally written down about this, but assuming it's under ssl, and I don't store any of the data (will store the cookies and tokens), what are the security implications?
If I come to your website and give you my gmail password, what guarantee do I have that you won't read all my emails and even send a few of your own? And what if you become a little smarter and say 'people reuse passwords, I might just as well try if this password works for his bank account'.
As a user, I don't trust your site with my password. Period.
The whole point of Open Id and OAuth (that's what RPX uses) is to get around the above issue. I can give your website restricted, revocable and configurable access to my facebook account, all without giving your website my facebook password.
The UI is confusing, I agree. But with time people will understand what its all about, and it will be a lot better.
As already said above:
The site (or the site owner) accessing your {google|yahoo|etc} account cannot be trusted not to change your password and kick you out of your account.
But I feel there are other good reasons:
Many people use the same password on more than one site ore account (some could have the same password on gmail and paypal) and the site owner could abuse that
The site owner doesn't want to be held liable for other site owners abusing your account
The site owner could not be able to store your username and password in secure fashion. The site needs to be able to access them automatically. So on the server hosting there is stored everything needed to access those credentials.
And the hosting usually happens in a shared or virtual server with the hosting company administrators (and sometimes - if the hosting company isn't too conscious - fellow users) able to access them.
Security and Confidentiality. Period.
Even some websites like Facebook discourage using this approach in their TOS i believe. If so, it will be illegal to do so.