Twilio-Csharp assemblies

I'm working on a project involving Twilio. My project is in .Net, so I of course use twilio-csharp. It's awesome for their REST API and for generating TwiML. I have just one problem with it. They force you to use Nuget and don't just provide you with assemblies. Now, I appreciate Nuget and all of that, but it doesn't work all that well with Mono. And, I prefer for my dependencies to be checked into SVN(in the form of a lib folder)

So, instead of working to get nuget installed and running under Mono, I instead just downloaded the source (latest as of July 6th, 2012) and built the assemblies myself. It's a bit of a pain because I'm making a web application. I'm not going to need the client functionality or any of that other stuff they include.

Anyway, here is the Twilio.Api.dll and the Twilio.Twiml.dll .. oh and Twilio.Api has a dependency on RestSharp.dll and Newtonsoft.Json.dll

If you like managing dependencies yourself like me, make use of the above links :)

Tags: .net
Posted: 7/6/2012 7:04:14 AM

FSCAuth Porting to PHP

Hello, I'll be honest with you all. FSCAuth was kind of a failure. It's awesome and all, but for some reason people just aren't interested in it.

I evaluated the .Net market and saw that quite a few people are happy with the (more difficult) Forms Authentication... But, there is one market that I was into years ago that had no official form of authentication, PHP. So, I looked into the existing PHP authentication solutions and saw, well a big lack of libraries out there.

So, I've began working on a port to FSCAuth to PHP. I aim to support all of the functions supported in the .Net version, with a few notable syntax-related changes that comes with porting to a different language. But basically, it should be capable of all of the same things. To list them again:

  1. Keeping track of salts(therefore allowing for Blowfish and similar algorithm support)
  2. Simple 4 function user store
  3. Easy to configure, just change a few configuration options, hook up the userstore to your database, and put the login calls in needed places in your application.

So, what's it going to look like? It'll basically look like the .Net version, a big static class.

Here is my test.php class:

<?php
  require("fscauth.php");
?>
...HTML code... 
<?php
  if(array_key_exists("test", $_GET) && $_GET["test"]==="1"){
    //try login
    FSCAuth::Login("foobar","password",false);
    echo '<br /> username: '.FSCAuth::GetCurrentUser()->Username;
  }else{
    //list user
    $user=FSCAuth::GetCurrentUser();
    if($user!=null){
      echo 'username: '.$user->Username.'<br />';
    }else{
      echo 'no one is logged in <br />';
    }

  }
?>

As you can tell, some of the syntax is a bit less.. intuitive, but this is a limitation of PHP.

But anyway, if you're a PHP developer and would like to beta test something like this, just drop me a line at earlz -at- this domain(lastyearswishes.com)

Also, in case you're wondering, the cookies generated WILL be compatible across the .Net and PHP version. So, if you have two applications that share login cookies, this is a very ideal use-case.

Posted: 7/3/2012 5:43:33 AM

All hail Microsoft

So I finally decided I should have a development environment setup in Windows to test against Microsoft's implementation of .Net. So pretty soon, I'll finally have Visual Studio 2008 Express running in Windows XP with Microsoft SQL Server Express installed. This is just for testing though really, my main priority(in hobby projects) is that it works on my own system

Posted: 3/22/2011 12:27:29 AM

We all make mistakes

Well, I was trying to not tie my website to MVC just for example sake, but I'm basically reinventing MVC the more I get into it. MVC isn't bad, but I'm not convinced it's the cure-all for every website like everyone else does.

Anyway, I could add some really neat possibilities to EView and EFramework by merging the two and making them directly dependable on each other. Well, EView I'd like to keep fairly independent because it has uses outside of the web. But EFramework I think could be a lot easier to use if views were built into it. This would allow me to make a few more assumptions making things easier for both me and the implementors.

But meh, I'll keep it how it is for now.

Posted: 3/9/2011 1:04:09 AM