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.
Related
On our intranet, I want to provide a website that certain employees can access. The work they do on the site will be recorded and tagged with their user-name for identification if the need should arise. Of course users have already logged in to their workstation and they have supplied credentials to our Active Directory.
Rather than maintain an additional set of user logins and passwords for the website, and forcing users to enter this second set of credentials, I am wondering if they can just be silently authenticated when they pull up the site? Somehow the webpage would have to find out their Active Directory user name as known on their workstation. (I see no reason it would need their password.) And then, for their work, the website can store their actions tagged with their user name.
So: I'd log in to my workstation as "Mark" in domain "ONU-AD". I'd pull up the webpage "resolveticket.php". That page would not challenge me for credentials, but it can access my username and store that with my various actions.
NOTE: I have seen some questions and answers here that were more specific. But my initial question is general: is there a piece of tech that can help with this? What is it? (for example, should I try to do this with Java?) Many similar questions are about ways to get this information in a server-side script. But I am simply wanting the webpage sitting on the client computer to be able to get the user name and perhaps place it in an input (type="hidden") on a web form.
My customer has an intranet portal and wants to have a button in it such that when clicking on it it would open my web site and login the user that was in the customer intranet automatically into my site.
The user, on both the intranet and my site, have the same user ID (the user ID is basically the email).
We do have IP authentication in place, so my site already knows the IP from where the intranet site is coming from, so that it authorizes it. Unauthorized IPs are redirected to kick them out.
How can my customer pass the user ID (aka the email in my case) from his Intranet to my web site, in such a way that it is secure?
Here are my concerns about being secure:
A) is the user ID is passed as a parameter to my web site (for example as part of the query string in the url or as a hidden input field in a form in a POST call), then there is the danger of anyone in that intranet altering this user ID by anyone else's user ID and entering as them. For example, if I am joe#abc.com, then joe#abc.com would be passed somehow from the intranet to the site as a parameter. I could easily make a change from joe#abc.com to dave#abc.com which would then log me in the site as dave#abc.com.
B) let's say that the user ID is then encrypted. So, now joe#abc.com becomes something like AAABBB000111. If I share this encrypted value with anyone, then this person could use the encrypted value and login as me. Of course I would have to share this encrypted value with him.
So, do you think that there is a good and elegant way to accomplish passing the user ID from the intranet to the external site in a secure way?
Query string can easily be used to pass this information over but if its secure i would not do that. You can pass it in a cookie which would be very easy again, If that isn't an option because the data is sensitive, you could look into sessionStorage to store the data temporarily between pages.
Sending it to the server sounds the best bet log them in save there session in a cookie and then redirect them.
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.
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.