Link to home
Start Free TrialLog in
Avatar of sfotadar
sfotadar

asked on

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
Avatar of php-webdesign
php-webdesign

what error do you get?
Avatar of sfotadar

ASKER

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
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?
Yes I get the right site.
But is there any workaround for this? If yes could you please let me know that...

Thanks,
SF
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

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&
Avatar of Nolan Mason
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
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...
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
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.
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.
Thanks WhitePhantom .. Do we have to modify these entries on the server hosting the web site or on the client PC.

Thanks,
SF
You have to modify the entries on the client computer that is trying to browse the web site.
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
I'm not sure that I understand your problem now.  Please elaborate.
Oh...I think I see what you mean.  You want to fix the problem from the server side so all clients can log in?
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!
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!
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
ASKER CERTIFIED SOLUTION
Avatar of COBOLdinosaur
COBOLdinosaur
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I don't think there is an answer to the asker's question.

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

Regards,
KB