I'm not quite sure what you're asking. TurboActivate allows users to use proxies. IsGenuine only fails when something is invalid or it fails to connect to LimeLM.
Proxy authentication bypass isgenuine
Hello, to test the behaviour of TurboActivate i'm using Fiddler2 as proxy.
If I enable in fiddler2 the "require proxy authentication" then in limelm isgenuine is returning 0, avoiding a possible license update.
In my opinion, isgenuine should return a sort of error and you should add to the SetCustomProxy a new option like:
Example 1 (just a host): http://127.0.0.1/Example 2 (host and port): http://127.0.0.1:8080/Example 3 (all 3): http://user:pass@127.0.0.1:8080/
New Example 4: http://user:pass@/ in which the server and port is the system one and just passed user and pass.
Hi Wyatt,I must correct my previous statement. If I enable proxy authentication in Fiddler2 LimeLM first tries to connect trough it without success cause of authentication, then it tries normally without proxy with success.
After noticing this I blocked the connection to our product forcing it to pass trough proxy and this gives error as I would expect.
The problem is that I don't want to specify a full proxy url when the only need is to specify a username and password.
For this i would like the fourth example
In which we pass the user and password but proxy address will be the system local one and TurboActivate will collect it by itself.
Well, TurboActivate needs to know the host. So if you're connecting to a local proxy server then just put in the localhost ip (127.0.0.1) or the hostname "localhost" (which is just 127.0.0.1). You can't just pass in the user and password and assume it will connect to 127.0.0.1. You have to state it explicitly.
Does that make sense?
Sure it make sense, but there can be cases where I don't want to pass my time trying to figure out which proxy it is trying to use and ask the correct password for it.
If you would parse the string that i made as example (just to be coherent with the previous ones) or if you will give one more function as SetCustomProxyLogin or whatever you would be able to pass this to the request if the proxy will ask for authentication.
In windows we just developed this for other situations, using HttpQueryInfo to find the status code and if it matches HTTP_STATUS_PROXY_AUTH_REQ we are setting the INTERNET_OPTION_PROXY_USERNAME e INTERNET_OPTION_PROXY_PASSWORD and then retrying the request once and repeating according to personal preference.
In this case if you would use the authentication information given from outside it will ease much the process of using a proxy.
We could add another error return code for error 407 (i.e. HTTP_STATUS_PROXY_AUTH_REQ). For instance, instead of failing with TA_INET it would fail with something like TA_INET_PROXY_AUTH_REQ. Then you could set the proxy with the username and password.
Would that be useful for you?
It will be more clear, but would force me still to find the proxy address somewhere in the pc of the user or to ask it to him.
I would like to be able to pass also just username and password to turboactivate.
There's a problem with just passing in a username and password into TurboActivate. The way TurboActivate works is that it detects *all* proxies on the computer (on Windows this involves asking Internet Explorer for all configured proxies). So if you just pass in a username and password TurboActivate would have to try it for all proxies on the system (whether the proxy requires a username and password or not).
Does that make sense?
We could make a compromise. For instance, we could detect if the proxy returns the 407 error code (i.e. username and password required) and then, if you have already supplied a username and password, try using that.
It's less than perfect because you still have no idea whether the proxy that returned 407 is the only proxy that requires a username and password. The best option in the case use user/pass protected proxies is to explicitly pass them into TurboActivate.
But would what I described be something you're looking for?
This would be perfect!
Ok, we'll add this to TA 3.2 (since we've already delayed it to do more testing).