Monday, November 14, 2016

A Base-64 Decoder That Works!

Let's face it...  debugging ASP.NET production websites can be challenging.  HTML sessions are 'stateless', meaning from one post to the next, the server has no idea what post came first.   For example, let's say there is a website that prompts the user for their name on one page, and on the subsequent page the user is prompted for their address.  Well, the server has no intrinsic way to join the data together from those two pages to save it all in a table somewhere.

Web scripting language use various methods to store this state information.  Some use cookies to store the data from one page to another.  Some use a unique key, placed into a cookie, or in the URL as a parameter to retrieve the data from an internal 'session store' on the server.  ASP.NET can save the session state several ways.  One way to save part of the session state is in something called a ViewState.  This is basically the state of a page; just part of the entire session state.

Well, this ViewState is stored right in the web page as a 64 bit encoded string.  It's not encoded but definitely looks that way.  It's unreadable without a decoder.  Anyway...  If something is stored in the ViewState, programmers can have a bitch of a time trying to pull it apart and see the data.  But...  This information can be invaluable to debugging a production problem.   There are varied ViewState tools on the web for decoding this gobeldygook into something that is somewhat coherent.  I use Base64 decoder and encoder at motobit.  It's simple and works.

Wednesday, November 9, 2016

So, Trump Is Our President

What the hell is this company coming to???  Think I will create a series of these...  Share as you wish.  Some may not be safe for work; you have been warned!

Sunday, November 6, 2016

Simple Is Still Simple

Yes, contrary to the conventional state of technology and computer programming, simple is still simple.  Well, at least it should be.

Quite frequently I read different articles about programming in an attempt to maintain professional relevance.   Some are well written articles on good programming techniques.  Some are poorly written but the core material is still good.  Some are well written pieces about some fluff fad and then there are occasionally the poorly written article about some programming technique or library or concept  that has 'bad idea' written all over it.

Monday, October 24, 2016

Solution to DDOS Attacks from the IoT

Last Friday, October 21st, the company DYN was the recipient of a rather massive DDOS (Distributed Denial of Service) attack.  Companies and tinkerers won't like this simple solution because it causes them to do a little extra work.  If this potential solution doesn't solve the problem, it would certainly mitigate it.

It's simple.  For those old enough to recall free AOL disks, remember how many included an account password printed on the CD/disk case?  Well, the same thing could be done for IoT devices.  Manufacturers of these things could simply print two random English words on a label and stick it on the IoT Device.  This password is burnt into the device as its factory default.  There is no standard factory default.  Let's face it...  The bulk of people using and installing IoT devices either don't know there is a password on their new-fangled refrigerator, or they just don't care to change it.

Seriously

water-wood
january-carolina
protien-curious
wrecked-quipped

These passwords would be so much better than admin or system or the ever-popular password.

Tuesday, October 18, 2016

Mouse Peep in a Snow Storm - or - How NOT to Operate QRP

So...  On last Sunday (2016-10-16) there was a little ham radio contest called the "Illinois QSO Party".  Yes, I am a licensed amateur radio operator, and have been continuously since 1983.  Since then I have talked to folks all over the world  from my car or home office, completely without this new-fangled thing they call the internet.

Anyway, my wife and I went to the Peoria Ham Fest several weekends ago and I bought a late 1970's Yaesu FT-7.  Sure, I would have preferred my favorite, an Icom IC-706, however my play-budget is currently quite limiting.  The Yaesu was only $200; the Icom runs around $700.  Add another $100 for antennas and other accessories, and the Icom will simply cost far too much right now.  At any rate, for $300 I purchased a rig and enough wire and coax to make antennas for the 80, 40, 20, 15 and 10 meter bands.

One thing...  The FT-7 is considered a QRP rig; that means 'low-power' for you non-hams out there.  Generally, this radio uses less power than a computer monitor.

Since tossing a 20M dipole up into the trees, I have been making regular contacts with mobiles on the County Hunter Net (14.336 MHz) and a few special events stations.  Signal reports are 'ok' but not outstanding.  This is how it works...  The other station "calls CQ" and is specifically listening for other stations to call them on a certain frequency.  They are listening.  So, when I call them with my little low-powered rig, they hear me and call me back.  It works.

I remember reading somewhere a long while ago that QRP stations really shouldn't call "CQ" (i.e. is anyone there).  It will be a waste of time.  Other hams tuning around the band might hear your puny little signal but move on to a louder signal because it is easier to make a contact with them.

Absolutely.  I wasted an hour on Sunday calling CQ with my little QRP radio during the Illinois QSO Party and made exactly zero contacts.

So, the common thought holds... When running QRP, don't call CQ...  It's like a mouse peep in a snow storm.

Thursday, September 22, 2016

Getting a 500 Error When Trying to Access a REST API from C#?

This just might be the solution.

Here's the deal...  I need to write a simple C# client to access data from a REST API served up by an Apache Tomcat server.  Not a big deal at all...  should be pretty simple...

Should be...

For some unknown reason, my attempts generated nothing but '500' errors from the server.  Myself and our resident network wizard captured my traffic and we compared the headers of a successful GET using CURL and the non-successful attempt using my simple C# program.

After trying a few things with no success, I noticed the CURL capture showed an 'Accept: */*' header.  My C# program did not.  So, I added this...

request.Accept = "*/*";

SHAZAM!!!  No more 500 errors.

No search results from Google helped.  None mentioned this as being a possibility.  But, heck...  it worked.

By the way, this Apache server is what I like to call LegalWalled.  Yes, it's our server but if we touch it, or even log onto it using SSH without the guidance and approval of the vendor's support group, we could violate our support contract...  so opportunity to dig into why that specific error was generated.


Monday, September 12, 2016

Yes... I did that... Don't remember it, but did it...

I am a programmer (or is that obvious?).  Once in a while I will be tasked with researching or changing a program that I originally wrote.  I get the most recent code from our Source Repository System and start reviewing the code.  There is no doubt the program came from my brain, but it is certainly not familiar.  Why did I put these functions into a DLL?  What was I thinking when I designed this junk table?  OMG, WHY did I use singe letter variables???  WHY?!?!?!?!?

Maybe this happens with people in other professions...  read this to mean I hope sincerely that any doctor, dentist, commercial pilot or member of law enforcement who feel a similar temporary disorientation should firmly consider taking the day off!

Does a mechanic one day, look at a half-rebuilt carburetor that they have been working on for a month and wonder what motorcycle it came from?  Does a blackjack dealer in Vegas pause and wonder what those cards with an "A" printed on them mean?  Does a baseball umpire call "STRIKE!" before the pitcher throws the balll?

Anyway...  Walter Bishop from Fringe may never have said this, but maybe he could have...