December 16, 2010

Making Calls With Twilio Sand Box

I have been playing with Twilio in the past weeks. It is pretty good and I have been able to send SMS from day one.
All good so far.
But I have failed miserably at placing calls.
Nothing showed in Twilio's debugger and it seemed as if nothing was even be triggered in Twilio at all.

Of course, I debugged my app (more details on that later) by pointing it to a mock Twilio service and it seemed to be doing everything it should. I have been pulling my hair over this issue for quite a while.
Sending SMS from my sandbox number, say +14156669999 to my cell, say +15127778888 works like a charm.... so why would placing a call from the same sandbox number to the same cell woud fail ? No idea. But that's just the way it is.

What you have to do is register one of your own numbers and initiate the call from the validated phone number to the cell number. The numbers I am talking about show in the Twilio account, on the "Phone Numbers" tab, in the section titled "My outgoing callerid numbers".
Unlike for SMS, you MUST use one of these numbers or Twilio just won't budge. Not even acknowledge that this is not what it expects....

be warned!

December 15, 2010

Easily Persist Java To Any Directory Server

Simply providing a trivial example to get you started.

The Meat
To make it really trivial, I will use a very simple object that already exists in the default schema, the person object class. This class only requires the person to have a first and last name, respectively stored in the cn (or commonName) and sn (or surname) attributes. To spice it up a bit and make it remotely useful, let's say we also expect a person to have a password so we can authenticate them later. The default schema allows us to do so in the userPassword attribute.

The whole idea of persistence is that you don't have to worry at all about the LDAP. All you need to do is 

>generate-source-from-schema -h localhost -p 389 -D "cn=directory manager" -w password --outputDirectory src/com/example --structuralClass person --rdnAttribute cn --defaultParentDN dc=example,dc=com --packageName com.example --className Person --terse

When you have done this, you have a in src/com/example created for you.
We'll go ahead and create a groovy script file in src/com/example to add a new guy in our directory server:

package com.example
import com.unboundid.ldap.sdk.LDAPConnection;
import com.unboundid.ldap.sdk.persist.LDAPPersister;
def cx = new LDAPConnection("localhost",389,"cn=directory manager","password")
def persister = LDAPPersister.getInstance(Person.class)
def newGuy = new Person()
persister.add(newGuy, cx, null)

That's it!
Yes, that really is it. Unbelievable? Try for yourself.

June 10, 2010

Make monitoring information publicly available

  For testing purpose or if you feel your network is safe enough or the monitoring information exposed does not compromise any sensitive data, you may want to easily be able to access your monitoring information anonymously. Here's how.

The Meat
With the default settings you'll get a silent response:

[unboundid@unboundid1 UnboundID-DS]$ bin/ldapsearch -p 1389 -b cn=monitor "(objectclass=*)"
[unboundid@unboundid1 UnboundID-DS]$ 

Let's make cn=monitor accessible publicly then: 
dsconfig set-access-control-handler-prop --add "global-aci:(target=\"ldap:///cn=monitor\")(targetattr=\"*\")(version 3.0; acl \"allow anonymous access to monitoring data\";allow (read,search) userdn=\"ldap:///anyone\";)"

And now:

[unboundid@unboundid1 UnboundID-DS]$ bin/ldapsearch -p 1389 -b cn=monitor -s base "(objectclass=*)"
dn: cn=monitor
objectClass: top
objectClass: ds-monitor-entry
objectClass: ds-general-monitor-entry
objectClass: extensibleObject
cn: monitor
productName: UnboundID Directory Server
productVendor: UnboundID Corp.
productVersion: UnboundID Directory Server
instanceName: unboundid1:1389
startupID: TBEplw==
startupUUID: 8cfc40a4-a176-410b-b5cd-f556b90f712f
startTime: 20100610180627Z
currentTime: 20100610203116Z
upTime: 0 days 2 hours 24 minutes 48 seconds
currentConnections: 2
maxConnections: 3
totalConnections: 14

April 26, 2010

Groovy+LDAP: How Easy Can It Get?

I was trying to simulate a particular client application this week end and I decided to go with a quick Groovy script. I decided to share here how easy it was to interact with server here.

The Meat
First things first, you should know to read the getting started guide, it makes it nice and easy for you to store your data in any LDAP server. I will break down here what needs to happen for you to do a search:
  1. get a connection
  2. issue the search
  3. get the results
And here is how it is done step by step:
  1. cx = new LDAPConnection("localhost", 1389, "cn=Directory manager", "password")
  2. result ="",SearchScope.ONE,"(objectclass=*)",null)
  3. result.getSearchEntries()
And now the complete groovy script that connects to your server and prints the results:
new LDAPConnection("localhost", 1389, "cn=Directory Manager", "password")?.search("o=company",SearchScope.ONE,"(objectclass=*)",null)?.getSearchEntries()?.each({println it.getDN()})

That's right!
One line is all you need to connect, search and print all entries DNs below the base which here is o=company.

Now that's easy!