Hi
Does this patch was commited to cvs??
Regards
On 9/27/07, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote:
> Alex,
>
> Didn't document it yet since it wasn't clear if it would make into CVS.
>
> I'll do it right away and post it here.
>
> Regards,
>
> Alejandro
>
> On 9/27/07, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> > Hi again,
> >
> > as I wrote patch looks good but I don't see userguide changes in the
> > patch :) Please update userguide and I will apply this patch if no
> > objections there.
> >
> > Alejandro Guerrieri wrote:
> >
> > > Did anyone reviewed this patch?
> > >
> > > On 9/7/07, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote:
> > >> The original condition was commented:
> > >>
> > >> + if (/*user == NULL || pass == NULL ||*/ /* we don't need this
> > >> anymore */
> > >> + octstr_compare(user, conndata->username) != 0 ||
> > >> + octstr_compare(pass, conndata->password) != 0) {
> > >> + error(0, "HTTP[%s]: Authorization failure",
> > >>
> > >> The piece of code you're referencing it's before the original (now
> > >> commented) evaluation. The purpose is to truly make user and password
> > >> optionals.
> > >>
> > >> And yes, you're absolutely right, it should be "||" to avoid
> > >> octstr_compare on an undefined value.
> > >>
> > >> Thanks for pointing this out. I've uploaded a new patch here:
> > >>
> > >> http://www.magicom-bcn.net/kannel/full-mo-http-params-20070907.patch
> > >>
> > >> Regards,
> > >>
> > >> Alejandro
> > >>
> > >>
> > >> On 9/7/07, Vincent CHAVANIS <[EMAIL PROTECTED]> wrote:
> > >> > Hi alejandro,
> > >> >
> > >> > I'm wondering why this condition has been changed
> > >> >
> > >> > if (user == NULL || pass == NULL) {
> > >> > user = octstr_create("");
> > >> > pass = octstr_create("");
> > >> > }
> > >> >
> > >> > into:
> > >> >
> > >> > if (user == NULL && pass == NULL) {
> > >> > user = octstr_create("");
> > >> > pass = octstr_create("");
> > >> > }
> > >> >
> > >> > I think that we need to check both of these values.
> > >> > if user = blah and password = NULL
> > >> > we will do octstr_compare with password and this is not safe.
> > >> >
> > >> > Vincent.
> > >> >
> > >> > --
> > >> > Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
> > >> > Service Technique/Reseau - NOC
> > >> > Developpement SMS/MMS/Kiosques
> > >> > http://www.telemaque.fr/
> > >> > [EMAIL PROTECTED]
> > >> > Tel : +33 4 92 90 99 84 (fax 9142)
> > >> > ----- Original Message -----
> > >> > From: "Alejandro Guerrieri" <[EMAIL PROTECTED]>
> > >> > To: "Alexander Malysh" <[EMAIL PROTECTED]>
> > >> > Cc: <[EMAIL PROTECTED]>
> > >> > Sent: Thursday, September 06, 2007 10:31 PM
> > >> > Subject: Re: [PATCH] Support for MO parameters on 'generic' HTTP SMSC -
> > >> > Secondrevision
> > >> >
> > >> >
> > >> > > Done,
> > >> > > Done,
> > >> > >
> > >> > > New version of the patch, using generic_receive_sms() instead of
> > >> > > kannel_receive_sms()
> > >> > >
> > >> > > http://www.magicom-bcn.net/kannel/full-mo-http-params-20070906.patch
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Alejandro
> > >> > >
> > >> > > On 9/6/07, Alexander Malysh <[EMAIL PROTECTED]> wrote:
> > >> > >> Hi,
> > >> > >>
> > >> > >> please doesn't change kannel http mode. Please define new MO
> > >> > >> function for generic HTTP mode instead.
> > >> > >>
> > >> > >> Alejandro Guerrieri wrote:
> > >> > >>
> > >> > >> > Hi,
> > >> > >> >
> > >> > >> > I've improved my patch and added extra flexibility. Now it's
> > >> > >> > possible to implement full clickatell functionality (including
> > >> > >> > DLR's) by properly configure the 'generic' http smsc.
> > >> > >> >
> > >> > >> > The patch is available here:
> > >> > >> >
> > >> > >> > http://magicom-bcn.net/kannel/full-mo-http-params-20070905.patch
> > >> > >> >
> > >> > >> > The patch allows for this new parameters on config:
> > >> > >> >
> > >> > >> > * This parameters allows to rename the proper MO parameters to
> > >> > >> > whatever you like:
> > >> > >> >
> > >> > >> > mo-from
> > >> > >> > mo-to
> > >> > >> > mo-text
> > >> > >> > mo-udh
> > >> > >> > mo-account
> > >> > >> > mo-binfo
> > >> > >> > mo-dlr-url
> > >> > >> > mo-dlr-mid
> > >> > >> > mo-flash
> > >> > >> > mo-mclass
> > >> > >> > mo-mwi
> > >> > >> > mo-coding
> > >> > >> > mo-validity
> > >> > >> > mo-deferred
> > >> > >> > mo-dlr-mask
> > >> > >> > mo-dlr-stat -> this special one allows you to rename the
> > >> > >> > message_id being returned by an external dlr confirmation, such as
> > >> > >> > clickatell's "status" parameter.
> > >> > >> >
> > >> > >> > For example, setting mo-from = whatever, then the "from" parameter
> > >> > >> > will be renamed "whatever".
> > >> > >> >
> > >> > >> > * This allows you to rename the return string the http generic
> > >> > >> > smsc returns:
> > >> > >> >
> > >> > >> > mo-ret-accepted
> > >> > >> > mo-ret-denied
> > >> > >> > mo-ret-unknown-dlr
> > >> > >> > mo-ret-missing-args
> > >> > >> > mo-ret-udh-mismatch
> > >> > >> > mo-ret-udh-long
> > >> > >> > mo-ret-auth-failed
> > >> > >> > mo-ret-dlr-accepted
> > >> > >> > mo-ret-dlr-denied
> > >> > >> >
> > >> > >> > For example, the mo-ret-accpeted allows you to change the "Sent."
> > >> > >> > text you get for anything else.
> > >> > >> >
> > >> > >> > Now comes the "new" features:
> > >> > >> >
> > >> > >> > id-from-reply -> When you send an MT message to an external http
> > >> > >> > smsc and you ask for a DLR, kannel "invents" a message_id. This
> > >> > >> > parameters allows you to get that message id from the external
> > >> > >> > source, effectively enabling the use of DLR's with clickatell. You
> > >> > >> > must fill this field with the text expected _before_ the
> > >> > >> > message_id. In the case of clickatell that's "ID:". So, if you get
> > >> > >> > "ID:12345678" the message_id will be "12345678".
> > >> > >> >
> > >> > >> > err-from-reply -> Same thing but for error id's.
> > >> > >> >
> > >> > >> > This 3 parameters allows you to map different external statuses to
> > >> > >> > kannel dlr statuses:
> > >> > >> >
> > >> > >> > dlr-success-regex -> maps to DLR_SUCCESS (0x08)
> > >> > >> > dlr-permfail-regex -> maps to DLR_BUFFERED (0x04)
> > >> > >> > dlr-tempfail-regex -> maps to DLR_FAILED (0x02)
> > >> > >> >
> > >> > >> > So, to implement clickatell's connectivity for MT and DLR's, you
> > >> > >> > just need to configure like this:
> > >> > >> >
> > >> > >> > group = smsc
> > >> > >> > smsc = http
> > >> > >> > system-type = generic
> > >> > >> > smsc-id = clicka
> > >> > >> > allowed-smsc-id = clicka
> > >> > >> > port = 15000
> > >> > >> > send-url =
> > >> > >>
> > > "https://api.clickatell.com/http/sendmsg?to=%p&from=%P&text=%b&api_id=NNNNNN&user=XXXXXX&password=PPPPPP&callback=3&deliv_ack=3&req_feat=8192";
> > >> > >> > status-success-regex = "ID" status-permfail-regex = "ERR"
> > >> > >> > status-tempfail-regex = "TEMP"
> > >> > >> > mo-dlr-mid = apiMsgId
> > >> > >> > mo-dlr-stat = status
> > >> > >> > id-from-reply = "ID:"
> > >> > >> > err-from-reply = "ERR:"
> > >> > >> > dlr-success-regex ="(004|008)"
> > >> > >> > dlr-permfail-regex = "(001|005|006|007|009|010)"
> > >> > >> > dlr-tempfail-regex ="(002|003|011)"
> > >> > >> >
> > >> > >> > I'll explain a little more:
> > >> > >> >
> > >> > >> > send-url points to the clickatell http api. A few parameters are
> > >> > >> > hardcoded, like api_id, user/pass, etc.
> > >> > >> > status-*-regex (current kannel functionality) is used to detect
> > >> > >> > whether the message was accepted by clickatell's api.
> > >> > >> >
> > >> > >> > mo-dlr-* is used to map the DLR parameters to kannel's own.
> > >> > >> >
> > >> > >> > id/err-from-reply is used to fetch the message/error id on MT from
> > >> > >> > clickatell's http response. This is mandatory for DLR's only.
> > >> > >> >
> > >> > >> > dlr-*-regex is used to map the different possible responses to
> > >> > >> > different kannel DLR status. So, if kannel responds with "004" or
> > >> > >> > "008" a DLR Success will be sent (0x08 for Kannel).
> > >> > >> >
> > >> > >> > I don't have a two-way account for clickatell, so I couldn't test
> > >> > >> > the MO part, but it should be as simple as to map the proper
> > >> > >> > parameters by configuring mo-* parameters and maybe mapping some
> > >> > >> > mo-ret-* strings also.
> > >> > >> >
> > >> > >> > Last by not least, the goal of this patch wasn't to replace the
> > >> > >> > clickatell interface, but to provide a generic mean to implement
> > >> > >> > other SMSC's without writing source code and recompiling. The
> > >> > >> > clickatell example was just that, an example of the capabilities
> > >> > >> > being added.
> > >> > >> >
> > >> > >> > I'd happily try to model other http smsc's (even extending the
> > >> > >> > patch to accomodate extra flexibility), just drop me a line in
> > >> > >> > private and send me docs about it.
> > >> > >> >
> > >> > >> > Regards,
> > >> > >>
> > >> > >> --
> > >> > >> Thanks,
> > >> > >> Alex
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Alejandro Guerrieri
> > >> > > Magicom
> > >> > > http://www.magicom-bcn.net/
> > >> > > LinkedIn: http://www.linkedin.com/in/aguerrieri
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Alejandro Guerrieri
> > >> Magicom
> > >> http://www.magicom-bcn.net/
> > >> LinkedIn: http://www.linkedin.com/in/aguerrieri
> > >>
> > >
> > >
> >
> > --
> > Thanks,
> > Alex
> >
> >
> >
>
>
> --
> Alejandro Guerrieri
> Magicom
> http://www.magicom-bcn.net/
> LinkedIn: http://www.linkedin.com/in/aguerrieri
>
>
--
|-----------------------------------------------------------------------------------------------------------------|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y
Nextel en México y en mas de 180 paises. Use aplicaciones 2 vias via
SMS y GPRS online
Visitenos en www.smsglobal.com.mx y www.pravcom.com
