Remote Debugging Chrome on Android with Windows

I’m an IPhone user. I like the device. I’m not a fanboy. I’m curious. So I got myself an HUAWEI P smart with Android Oreo (Version 8).1. Lets set up developer mode by following the android studio guide…Open the Settings appSelect System (only on Android 8.0 or higher) Scroll to the bottom and select “About phone”Scroll to the bottom and tap “Build number” 7 times–Whaaaaat? Tap? Seven times? Really 7?Return to the previous screen to find “Developer options” near the bottom2. Connect to the PhoneDownload the Android SDK Platform-ToolsExtract the filesConnect the phone using USB cableRun the Android Device Bridge (ADB) on the computer “adb devices”Enable USB debugging on the device settings and authorize the computerRun “adb devices” againRun “& ./adb forward tcp:9222 localabstract:chrome_devtools_remote”3. Connect Chrome to the deviceOpen ChromeHit [F12] to open the DevToolsClick Settings | More Tools | Remote devices4. Start DebuggingClick on the device you connected in the DevTools remove devices windowOpen a new tab or select an existing oneClick Inspect to open the remote inspection windowHTH

W3C Server Timing Header and API

I used custom headers in the past to send some metrics over to the client–mostly for debugging purposes to quickly differentiate between client and server issues on slow web request and/or web application performance.While that was working out pretty well I like standards and even if I did not tell anybody I always wanted such a thing built into HTTP.A W3C standard is on the way: Server TimingIt consists of a spec how the HTTP Header is constructed: And a client side API for JavaScript: Of course not all browsers support it yetBut Chrome 65–at the time of writing in the beta channel–does so:Even without any extra JavaScript you can inspect the numbers sent with the header in the Network tab of the DevTools:

Scheduled task to automatically delete Fiddler HTTPS interception certificates

I really like Fiddler, the web debugger. I like TLS. I develop software. Therefore I find the interception and decryption of secure traffic very useful.On the other hand I’m into security for a few years now and from that perspective it is a man in the middle attack. So you might want to allow this for the shortest period of time.Fiddler installs a Trusted Root Certificate and dynamically issues certificates for the requested targets for the requested host names. This messes up the certificate store and under certain circumstances leaves risk for potential abuse of these certificates – which are trusted on your machine.So let’s do some automation to clean up. First a few lines of PowerShell:And Finally a scheduled task to import that runs on log on:HTH

Why Microsoft's Browser Developer Tools suck

Ok, this is kind of a rant post. I acknowledge that Microsoft is really really doing a good job at certain (developer) spots (ASP.NET, Visual Studio, IIS, SQL Server, …). But NOT at the browser developer tools – I’m listing my issues here, hoping the IE-Team will listen and make the world better for everybody. Dev Tools Pinning Location Why can’t I pin the developer toolbar on the right side as in every other browser. Screens with 4:3 have gone. Widescreen is the standard. Pinning at the bottom makes no sense to me (in most cases). Edge IE11 Firefox Chrome Opera Open Developer Tools At Start Tab In Edge the ability to open developer tools is disabled … for whatever reason:   In internet explorer with about:blank this was possible… Q: So how can i network trace an initial request? A: Go somewhere else, Hit F12, then do what you originally wanted to do #this-is-not-intuitive Opera, Chrome, Firefox Explicit enablement of network trace (<Win10) Thank you for fixing that on Windows 10 – in IE11 on Win 8.1 it’s still disabled by default. Please offer an update for IE/<Win10. Initiator of network request (<Win10) Thank you for fixing that on Windows 10 – in IE11 on Win 8.1 it’s still shows <script> and not the specific script with line and char. Please offer an update for IE/<Win10. IE11.0.9600.18161/Win8.1 IE11.63.10586.0/Win10 Dockability of Tools Window Thank you for fixing that on Edge – In IE 11 the tools window cannot be docked with [Win] + [left|right]. Dark Theme FF developer edition does it. Chrome can do it. IE and Edge lack a dark theme, seriously. Call to action So c’mon Edge Devs. Make the web developers life easier. surprise us. you can do better!

Handling Request too large and identify limits in ASP.NET

For security reasons request sizes are limited by default. This is configurable in the web.config file through the httpRuntime sections maxRequestLength attribute. The value is an integer and it’s default value is 4096 (KB) and therefor is 4,153,344 bytes or 4 MB. The configured values can easily be read using the .NET configuration API: If an request is larger than this value a HttpException is thrown when the HttpRequest properties Forms, Files or InputStream are accessed. The HttpException class has a property named WebEventCode which contains a value of the WebEventCodes lookup class: RuntimeErrorPostTooLarge which is an integer with the value 3004. If you catch this exception you can handle the error in your application code and for instance return a custom error message. But… When hosted in Internet Information Services (IIS) there might be another barrier: The request filtering module. This also has a section to configure the maximal length of a request using the requestLimits section and its maxAllowedContentLength property. By default this is set to 30,000,000 (bytes) and therefore is 29.297 KB or 28.61 MB. If this limit is hit IIS will return a HTTP error 404 with sub status code 13 with the reason phrase “Content Length Too Large”. The .NET configuration API refuses to load this section. And even if accessed raw using the system.webServer sections SectionInformation property and its GetRawXml method the possible inheritance is not reflected. So values configured on server and not on site level divergent from the default cannot be found here. IIS at startup create a configuration file located at *{windows drive}\inetpub\temp\appPools\{appPoolName}\{appPoolName}.config. The IIS application pool identity (the account running our web application) of course has read access to the file. To build up the path we need to get the application pool name at runtime. There is a server variable called APP_POOL_ID that will provide the neccessary information. The following code get the local overwritten values from the web.config, the server level configured, the default value or null if request filtering is not installed: At application startup the configuration can now be validated – request filtering schould always have a bigger value when you want to handle these kind of errors in your application code – and the values of a maximal request length can be read and possibly displayed.

Using credentials based on a SecureString that is disposed

Today I was building a credential store API. One implementation against the Windows Credentials Manager (CredMan), the other one persisting information in a database. Of course the data is not persisted in clear text. I use either the MachineKey functionality or a RSA certificate based encryption.So far so good, but I want the passwords to be secure in memory to. The .NET Framework already has a Type built in for that purpose: SecureStringThe SecureString class implements the IDisposable interface and having a property in a class of that type means losing control of the destruction.The implementation will return ICredentials instances to authenticate mostly web requests or provide proxy authentication. So I created a test to figure out how the combination of NetworkCredential and SecureString behaves. All green – It’s possible to use a NetworkCredential object that is constructed with a SecureString even after the SecureString has been disposed. Looking inside the credential object using redgate's Reflector reveals that NetworkCredential internally uses the copy method to clone the SecureString. When a normal string is passed to the constructor it is wrapped into a SecureString also.Sadly the NetworkCredential class does not implement IDisposable. So the issue is carried out to the user code.Keep in mind: When using NetworkCredential to call SecurePassword.Dispose() after the credentials aren’t required any more!

Batch processing Visual Studio ProjectItems with the Nuget Package Management Powershell Console

Today I helped a customer to minify and bundle a bunch of JavaScript files. We used WebGrease triggered from MsBuild to do the job. The next thing to do is changing the BuildAction property on all non-bundled-and-minified JavaScript files so that only minified and bundled files are published. Here is my script: Hope that helps

Bye bye RFC2616, Welcome RFC 723X

The IETF has published a bunch of new RFCs to update HTTP/1.1 specs and make the 15 year old 2616 obsolete: RFC 7230: Message Syntax and Routing RFC 7231: Semantics and Content RFC 7232: Conditional Requests RFC 7233: Range Request RFC 7234: Caching RFC 7235: Authentication RFC 7236: Authentication Scheme Registrations RFC 7237: Method Registrations RFC 7238: the 308 status code RFC 7239: Forwarded HTTP extension Here I listed a few changes: Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. Header fields that span multiple lines ("line folding") are deprecated. Bogus Content-Length header fields are now required to be handled as errors by recipients. Gateways do not need to generate Via header fields anymore. The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried. The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. The semantics of the Upgrade header field is now defined in responses other than 101 The Expect header field's extension mechanism has been removed due to widely-deployed broken implementations. The "about:blank" URI has been suggested as a value for the Referer header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not sent or has been removed. The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness information present): 204, 404, 405, 414, 501. The 201 (Created) status description has been changed to allow for the possibility that more than one resource has been created. Method Registry: http://www.iana.org/assignments/http-methods/http-methods.xhtml Status Code Registry: http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml Happy reading, happy implementing!