When I try to run FiddleApplication.Startup(startupConfig)
FiddlerCoreStartupSettings startupSettings = newFiddlerCoreStartupSettingsBuilder()
.ListenOnPort(0)
.RegisterAsSystemProxy()
.DecryptSSL()
.Build();
FiddlerApplication.Startup(startupSettings);
In my log events I see:
Starting FiddlerCore/4.6.20191.7809 (NoSAZ)...
** LogString: !WARNING: The DefaultLAN Gateway information could not be obtained.
** NotifyUser: Error - Failed to register Fiddler as the system proxy.
I'm running the process as administrator.
Note: When I run the normal Fiddler UI application everything works fine. Even running an older FiddlerCore version (2.3) is able to register itself as the system proxy.
P.S - I also see a warning in Visual Studio - "Please use Telerik.NetworkConnections.NetworkConnectionsManager to register the FiddlerCore Proxy as the system proxy." But I couldn't find any documentation/examples using NetworkConnectionsManager and I couldn't figure out how to use it.
Related
I've validated the MSAL auth path using the desktop PowerShell 5.1 and 7.0 applications. However, all of the authentication paths which worked on the desktop are not working in CloudShell -
PS /home/michael/CSTest/0.0.2/MicrosoftTeams> connect-microsoftteams
Connect-MicrosoftTeams: One or more errors occurred. (Unable to open a web page using xdg-open. See inner exception for details. Possible causes for this error are: xdg-open is not installed or it cannot find a way to open an url - make sure you can open a web page by invoking from a terminal: xdg-open https://www.bing.com )
Connect-MicrosoftTeams: Unable to open a web page using xdg-open. See inner exception for details. Possible causes for this error are: xdg-open is not installed or it cannot find a way to open an url - make sure you can open a web page by invoking from a terminal: xdg-open https://www.bing.com
Connect-MicrosoftTeams: No such file or directory
Connect-MicrosoftTeams: One or more errors occurred. (Unable to open a web page using xdg-open. See inner exception for details. Possible causes for this error are: xdg-open is not installed or it cannot find a way to open an url - make sure you can open a web page by invoking from a terminal: xdg-open https://www.bing.com )
PS /home/michael/CSTest/0.0.2/MicrosoftTeams> connect-microsoftteams -UseDeviceAuthentication
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BRZPG2UNE to authenticate.
Connect-MicrosoftTeams: One or more errors occurred. (Windows Data Protection API (DPAPI) is not supported on this platform.)
Connect-MicrosoftTeams: Windows Data Protection API (DPAPI) is not supported on this platform.
Connect-MicrosoftTeams: One or more errors occurred. (Windows Data Protection API (DPAPI) is not supported on this platform.)
PS /home/michael/CSTest/0.0.2/MicrosoftTeams> connect-microsoftteams -AccountId miluong#microsoft.com
Connect-MicrosoftTeams: One or more errors occurred. (Federated service at https://msft.sts.microsoft.com/adfs/services/trust/13/windowstransport returned error: )
Connect-MicrosoftTeams: Federated service at https://msft.sts.microsoft.com/adfs/services/trust/13/windowstransport returned error:
Connect-MicrosoftTeams: Federated service at https://msft.sts.microsoft.com/adfs/services/trust/13/windowstransport returned error:
Connect-MicrosoftTeams: One or more errors occurred. (Federated service at https://msft.sts.microsoft.com/adfs/services/trust/13/windowstransport returned error: )
How do I enable support for managed identity?
How do I get interactive auth flow to work without xdg-open? Currently CloudShell does not install xdg-open
Is there a recommended path to try to acquire a token without DPAPI? CloudShell works in a Linux environment and DPAPI only supports Windows.
Do you know of any PS modules which use MSAL that are working in CloudShell?
xdg-open does not work and is not planned to be supported in CloudShell
The DPAPI error was because I was trying to protect the token by encrypting it at rest
Integrated Windows Authentication is not a supported workflow in CloudShell because it's a Linux based environment.
I'm using Worklight 6.2 server edition and I can't deploy a working runtime (of other environments) on my server.
I'm using webpshere liberty profile v8.5.5 and when I deploy the runtime via GUI it says success and on server.xml I can see the new configuration for the app.
However when I go to the worklightconsole I don't see my runtime to upload the app.
On messages.log there is a error regarding JMX connection.
The quoted error is
Failed to obtain JMX connection to access an MBean. There might be a JMX configuration error: No JMX connector is configured
I'm refering this because I've seen some post on SO saying that these issues might be connected. However I have the restConnector-1.0 on my WLP features.
Reference: No runtime on my Worklight 6.2 Console after installing analytics
On messages.log there is some other things that I found interesting, like the correct start of the runtime I've deployed
[11/12/14 5:50:45:177 CST] 00000012 com.worklight.server.bundle.project.JeeProjectActivator I FWLST0002I: ========= Project /HelloWorld started. The project WAR file version is 6.2.0.00.20140922-2259,running on server version 6.2.0.00.20140613-0730. [project HelloWorld]
and two erros while starting my server
[11/12/14 5:50:49:911 CST] 00000012 SystemErr R 24 WorklightPU WARN [Scheduled Executor-thread-1] openjpa.Runtime - An error occurred while registering a ClassTransformer with PersistenceUnitInfo: name 'WorklightPU', root URL [file:/opt/IBM/WebSphere/Liberty/usr/shared/resources/worklight/lib/worklight-jee-library.jar]. The error has been consumed. To see it, set your openjpa.Runtime log level to TRACE. Load-time class transformation will not be available.
Second error:
java.lang.RuntimeException: Timeout while waiting for the management service to start up
I don't know what these are but I think it might be related to my problem and this errors eventually appear when I start my server.
Does anyone have any tips for troubleshooting this issue?
Thanks in advance.
This is a known issue from Websphere.
There is a APAR to fix that, a workaround is to restart the server with the --clean option to force a refresh onto the shared libraries.
http://www-01.ibm.com/support/docview.wss?uid=swg1PI17830
On Development Server, whenever I add an taskqueue
taskqueue.add(queue_name='default', url='/_tasks/do_something', params={'key': 1})
The following error occurred
taskqueue_stub.py:1974] Task task1 failed to execute. This task will retry in 819.200 seconds
After getting some hint from this post:
http://www.rogerthat.net/2012/03/27/google-app-engine-push-task-queues-the-development-environment/
I suspect it could be something to do with the hostname. I am using http://test.me:8088 (where test.me point to 127.0.0.1 using host file). The problem goes away when I change the hostname (test.me) to "localhost".
I can't just use localhost due to some app configuration issue.
The code edit rogerthat.net point out is no longer valid.
Any other solution?
I use windows 7, apache 2.2.22 at port 80 and geoserver 2.1.3 at port 8080.
I download and run kaazing 3.5 msi x64 installer to install it locally on my laptop. I followed the official guidelines from the site. The msi succesfully installed the gateway.
But gets installed in C:\Applications Files\etc. not in C:\Program Filesx68\etc.
Anyhow, I tried to start the services, I ran the demo-services.start.bat and a notification came from windows saying that the Windows Fire Wall has blocked some of the features of java. So I hit "Allow" and wait. Command line says something like
"Sending data to ucd://localhost/50505, ucd://localhost/50506"
for over an hour, nothing happens. So I thought something went wrong with windows and java. I uninstall the kaazing, edit the Windows Fire Wall settings to allow java and re-install kaazing. The notification is not showing up now, but when I ran the demo-services.start.bat, still does nothing, just says the same thing. When I visit
http://localhost/8000
gives an 404 error.
I tried everything, chanching ports, uninstall and re-install a couple of times, installing while not connected to the internet, checking the windows fire wall settings, manually running demo-services.start.bat and gateway.start.bat . The gateway.start.bat actually runs ok and says that the gateway started, but still an 404 error when I visit localhost/8000. Installation through msi is always completed with no errors. But the Gateway does not work. Is it the fire wall, the demos bat file, I dont get it...
Tips/hints?
The first thing to do is get the Gateway running successfully first. So don't worry about running demo-services.start.bat yet.
From the Windows Services application, start Kaazing WebSocket Gateway. Then go to C:\Program Files\Kaazing, locate your installation and look in the log directory. Open error.log using a text editor and verify there are no errors.
If there are no errors, you should be able to open http://localhost:8001 from a browser. (Note, you had http://localhost/8000 in your example, but that last slash should be a colon.) You can use either port 8000 or 8001, but 8001 is where the samples are.
If you are using a firewall or something else that is intercepting ports, then you'll need to make sure ports 8000 and 8001 are accessible.
If you're not sure, start a different server process on port 8000 or 8001 (e.g. configure Apache to listen on port 8000 or 8001) and see if the browser can connect.
The msi succesfully installed the gateway. But gets installed in
C:\Applications Files\etc. not in C:\Program Filesx68\etc.
The Gateway is not an executable itself, but runs in a JVM. Therefore there is no 32bit code which constrains the application to be installed into C:\Program Files (x86). Thus C:\Program Files made the most sense.
You could use a 32-bit JVM which would reside in C:\Program Files (x86), but the Kaazing files are abstracted from that via Java, so C:\Program Files is a reasonable location for the Gateway.
BTW There is a forum on the Kaazing website for Kaazing questions.
I upgraded to GAE 1.7.7 today and found out that task queues stopped working on my development setup.
I'm using https on my development environment through an nginx set up to proxy the connections from fakedomain.local:80 and fakedomain.local:443 to localhost:8080 (where GAE listens).
With this setup, taskqueues end up being created to be executed at fakedomain.local:80. This used to work because the request would be picked up by nginx, but the version 1.7.7 of the development server seems to have a port registry which won't serve a request unless the port is known (if I understand google.appengine.tools.devappserver2.Dispatcher._resolve_target correctly). Of course, GAE listens on port 8080 and my tasks marked to run on fakedomain.local:80 never get executed (GAE logs this error: An error occured while sending the task "task1" (Url: "...") in queue...).
I tried patching dispatcher.py:577 so instead of raising a ServerDoesNotExistError when the port is not known it will just use the default server. With this modification I can get the taskqueues running again, but I'd rather use a solution which doesn't involve changing GAE's code.
How can I make GAE register the port 80 and 443 in version 1.7.7? Alternatively, is there a way I could specify the complete target URL for the task? (ie fakedomain.local:8080/my_task, instead of just /mytask).
taskqueue.add(target=taskqueue.DEFAULT_APP_VERSION, ...)
will run it on your default app, which should do exactly what you want.
taskqueue.DEFAULT_APP_VERSION =>
app_identity.get_default_version_hostname() =>
environ['DEFAULT_VERSION_HOSTNAME'] =>
'%s:%s' % (environ['SERVER_NAME'], server_port)