• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 268173
  • Last Modified:

Http://username:password not working

Hi..
I have a  link on my web site which is pointing to a sercure web site using http://username:password@Sitename. Earlier it user to work now it does not work because of the IE patch. Could you please suggest a workaround for this issue.

Thanks,
SF
0
sfotadar
Asked:
sfotadar
  • 8
  • 8
  • 2
  • +5
1 Solution
 
php-webdesignCommented:
what error do you get?
0
 
sfotadarAuthor Commented:
It gives me the page caanot be found error. On the secure site we have basic authentication and I don't want user to see the login pop up window when clicking the link.

Thanks,
SF
0
 
php-webdesignCommented:
when you remove the username and pass from the link... and enter it in the password field... do you get the the right site then?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
sfotadarAuthor Commented:
Yes I get the right site.
0
 
sfotadarAuthor Commented:
But is there any workaround for this? If yes could you please let me know that...

Thanks,
SF
0
 
sfotadarAuthor Commented:
I have this requirement in my project where we are redirecting a user to a another of our own site. Since the user has already logged in from site1 we don't want the user to see the authentication login on the second site.

I also think there should be a legitmate solution for this. But before saying to my boss that there is no way to do this I wanted to make sure that there is no legitmate solution for this.
 

Thanks,
SF

0
 
COBOLdinosaurCommented:
So we should leave it here for a while and see if there isa solution.  The problems created by SP2 are new and some solutions are still to be found for some things.

Cd&
0
 
WhitePhantomCommented:
I worked around this exact problem a long time ago by using information provided near the end of the following Microsoft KB Article.  I don't want to give specifics, just in case my answer could be deemed as providing hacker info, but here's what Microsoft has to say about it.

http://support.microsoft.com/default.aspx?scid=kb;en-us;834489
0
 
OliWarnerCommented:
COBOLdinosaur, i'm wondering why a work around to allow people to type their un/pass in a url is such a problem? i do it all the time to save.. err.. time...

I understand its not entirely secure but passing passwords over the internet even if you typed them in a box isnt secure as they's no security cert layer...

Moreover, why would this be an infringement of any EE rules because the author looks like they're looking to find a time-saver, not hack the pentagon...
0
 
sfotadarAuthor Commented:
Hi WhitePhantom I looked at the above link but could not make it work. Since microsoft is suggestign workaround for the above problems can we discuss the solution which microsoft is suggesting which I think should be a legitimate solution. COBOLdinosaur  will it be ok if we discuss the solution suggested by microsoft.

thanks,
SF
0
 
WhitePhantomCommented:
The article does describe how to work around this problem by putting entries into the registry.  I tested that this works only three minutes ago, with and without the entries.  Since you say it's ok to discuss information in that article, I will be more bold in my answer.

Quote:
"
How to disable the new default behavior for handling user information in HTTP or HTTPS URLs
To disable the new default behavior in Windows Explorer and Internet Explorer, create iexplore.exe and explorer.exe DWORD values in one of the following registry keys and set their value data to 0.
For all users of the program, set the value in the following registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE

For the current user of the program only, set the value in the following registry key:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE
"

You have to actually create the "FEATURE_HTTP_USERNAME_PASSWORD_DISABLE" keys under FeatureControl, as it does not already exist.  You must then create the iexplore.exe and explorer.exe DWORD values.  Since they will already be set to zero, there's no need to change the default values.  To make this easy for sfotadar, I would be more than happy to post text for a registry import, but I'm not sure if that would be allowed.
0
 
WhitePhantomCommented:
Sorry, I should clarify...I meant that I tested both with and without the entries that making this modification to the registry is a successful workaround to this problem.
0
 
sfotadarAuthor Commented:
Thanks WhitePhantom .. Do we have to modify these entries on the server hosting the web site or on the client PC.

Thanks,
SF
0
 
WhitePhantomCommented:
You have to modify the entries on the client computer that is trying to browse the web site.
0
 
sfotadarAuthor Commented:
Oh I see...This won't work in my case since our web site is the internet site and anybody can log to ur web site. Could you suggest any other solution for this..

Thanks,
SF
0
 
WhitePhantomCommented:
I'm not sure that I understand your problem now.  Please elaborate.
0
 
WhitePhantomCommented:
Oh...I think I see what you mean.  You want to fix the problem from the server side so all clients can log in?
0
 
WhitePhantomCommented:
Ok, this information may be helpful.  It is another quote from the KB article I pointed to in my first post.

"
Workarounds for application and Web site developers

URLs that are opened by objects that call WinInet or Urlmon functions
For objects that use an HTTP or an HTTPS URL that includes user information when they call a WinInet or Urlmon function such as InternetOpenURL, rewrite the object to use one of the following methods to send user information to the Web site:
Use the InternetSetOption function and include the following option flags:
INTERNET_OPTION_USERNAME
INTERNET_OPTION_PASSWORD
Note For these flags, the InternetSetOption option must have a handle returned by the InternetConnect function. Therefore, if the application uses the InternetOpenUrl function, modify the application to use the InternetConnect, HttpOpenRequest and HttpSendRequest WinInet functions. For additional information about how to use these functions, visit the following Microsoft Web sites:
http://msdn.microsoft.com/library/en-us/wininet/wininet/internetconnect.asp

http://msdn.microsoft.com/library/en-us/wininet/wininet/httpopenrequest.asp

http://msdn.microsoft.com/library/en-us/wininet/wininet/httpsendrequest.asp

Use the IAuthenticate Interface. For additional information about how to use the IAuthenticate Interface, visit the following Microsoft Web site:
http://msdn.microsoft.com/workshop/networking/moniker/reference/ifaces/iauthenticate/iauthenticate.asp

Note With this workaround, you can open Web sites that the URL-spoofing technique redirects. The whole URL appears, including the redirected location. For example, the following URL appears:
http://www.wingtiptoys.com@www.example.com

The user still arrives at the redirected Web site. In this example, the user arrives at http://www.example.com.
"

If that does not help, there is most likely something in the Microsoft KB article that will give you the info you need.

http://support.microsoft.com/default.aspx?scid=kb;en-us;834489

Sorry that I can't be more help than this.  Good luck!
0
 
tomvergoteCommented:
why would you want to put the username:password in the url/link?
so it could be sniffed by anybody???
Do you even realise that this way anybody could grep (parse) a username:password list from the proxy logs.
it's not even a https link.

running an unpatched internet explorer would be an insignificant risk to the username-in-url cluelessness.

Oh, and i've got a splendid solution for you, no browser exploits and working with the username:password stuff:
standardize on firefox!
0
 
sfotadarAuthor Commented:
That is the requirement of the client. They don't want to enter user name and password twice. Do you have any suggestions ??

Thanks,
SF
0
 
COBOLdinosaurCommented:
>>> That is the requirement of the client.

Tell the client that it is no longer possible because M$ has tighened security.

Cd&
0
 
WhitePhantomCommented:
I don't think there is an answer to the asker's question.

WP
0
 
tomvergoteCommented:
I'm voting for COBOLdinosaur because imo his is the best solution
0
 
TripicCommented:
If you are using a a form to login use GET instead of post and just use Pull information from URL
0
 
kbrcCommented:
It is true that Microsoft has stopped providing this facility anymore. It is no longer available with IE's new patch.

Regards,
KB
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 8
  • 8
  • 2
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now