Re: [SR-Users] Authentication Feature Question

Hello, On 1/3/12 10:08 PM, Ali Jawad wrote: > > Hi > > In Xlite/eyebeam I put in the username and one of my 3 kamailio > servers respectively as the sip registrar, I.e. register1.domain.com, > register2.domain.com and register3.domain.com, that is why I was > saying that hashing will create different hashes based on the register > domain.  With reference to my first related post, one kamailio server > is for softphones, one for sip devices and one for mobile phones with > SIP software. Each server has a slightly different NAT and Call > routing structure. but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices. > This is why I wanted to eliminate the domain factor from the hashing > procedure, I am sure it chooses the right value from the DB  value > because it is the same value shown in the log of kamailio against > which a comparison is being done and because it works if I put > register.domain.com in the domain column rehash the HA! value of the > db. When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message. Check to see if the xlite does not have a realm field that has to be set properly. >>>>>> values at 0xb7b78dac >>>>>>> >>>>>>>  5(18649) DEBUG:<core>          [db_val.c:117]: converting STRING >>>>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>>>>> the DB based on domain.com >>>>>>>  5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears >>>>>>> to >>>>>>> be the value generated register.domain.com >>>>>>>  5(18649) DEBUG: auth [api.c:220]: check_response: Authorization > > How can I enable the SQL query log ? I don't know by hart, googling should help you. Cheers, Daniel > On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla > &lt;miconda(a)gmail.com&gt;    wrote: >> >> Hello, >> >> why are you using register.domain.com as domain for registration? >> Isn't >> domain.com the right one? >> >> Can you enable the sql query log for mysql server and double check if >> the >> right value (column) is selected from the database table? >> >> Cheers, >> Daniel >> >> >> On 1/3/12 5:13 PM, Ali Jawad wrote: >>> >>> Hi >>> Please see the below, thanks ! >>> >>> interface: eth1 (xx.xx.xx.0/255.255.255.0) >>> match: support1 >>> >>> U +6.698682 yy.yy.yy.146:18832 ->      xx.xx.xx.51:5060 >>> REGISTER sip:register.domain.com SIP/2.0. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. >>> Max-Forwards: 70. >>> >>> >>> >>> Contact:<sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>. >>> To: "Test Ast"<sip:support1@register.domain.com>. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=f710b930. >>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >>> CSeq: 1 REGISTER. >>> Expires: 3600. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>> SUBSCRIBE, INFO. >>> User-Agent: eyeBeam release 1102q stamp 51814. >>> Content-Length: 0. >>> . >>> >>> >>> U +0.005245 xx.xx.xx.51:5060 ->      yy.yy.yy.146:18832 >>> SIP/2.0 401 Unauthorized. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >>> To: "Test >>> >>> >>> Ast"<sip:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=f710b930. >>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >>> CSeq: 1 REGISTER. >>> WWW-Authenticate: Digest realm="domain.com", >>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >>> Server: kamailio (3.2.1 (i386/linux)). >>> Content-Length: 0. >>> . >>> >>> >>> U +0.428042 yy.yy.yy.146:18832 ->      xx.xx.xx.51:5060 >>> REGISTER sip:register.domain.com SIP/2.0. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. >>> Max-Forwards: 70. >>> >>> >>> >>> Contact:<sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>. >>> To: "Test Ast"<sip:support1@register.domain.com>. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=f710b930. >>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >>> CSeq: 2 REGISTER. >>> Expires: 3600. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>> SUBSCRIBE, INFO. >>> User-Agent: eyeBeam release 1102q stamp 51814. >>> Authorization: Digest >>> >>> >>> >>> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. >>> Content-Length: 0. >>> . >>> >>> >>> U +0.005146 xx.xx.xx.51:5060 ->      yy.yy.yy.146:18832 >>> SIP/2.0 401 Unauthorized. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >>> To: "Test >>> >>> >>> Ast"<sip:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=f710b930. >>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >>> CSeq: 2 REGISTER. >>> WWW-Authenticate: Digest realm="domain.com", >>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >>> Server: kamailio (3.2.1 (i386/linux)). >>> Content-Length: 0. >>> . >>> >>> [root@kam-rtp-100-51 mysql]# mail alijawad1(a)gmail.com&lt; >>>  output.txt >>> [root@kam-rtp-100-51 mysql]#  ngrep -W byline -T support1  -q -d eth1 >>> interface: eth1 (xx.xx.xx.0/255.255.255.0) >>> match: support1 >>> >>> >>> >>> >>> U +5.321505 yy.yy.yy.146:63610 ->      xx.xx.xx.51:5060 >>> REGISTER sip:register.domain.com SIP/2.0. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. >>> Max-Forwards: 70. >>> >>> >>> >>> Contact:<sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>. >>> To: "Test Ast"<sip:support1@register.domain.com>. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=ba705453. >>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >>> CSeq: 1 REGISTER. >>> Expires: 3600. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>> SUBSCRIBE, INFO. >>> User-Agent: eyeBeam release 1102q stamp 51814. >>> Content-Length: 0. >>> . >>> >>> >>> U +0.004782 xx.xx.xx.51:5060 ->      yy.yy.yy.146:63610 >>> SIP/2.0 401 Unauthorized. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. >>> To: "Test >>> >>> >>> Ast"<sip:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=ba705453. >>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >>> CSeq: 1 REGISTER. >>> WWW-Authenticate: Digest realm="domain.com", >>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >>> Server: kamailio (3.2.1 (i386/linux)). >>> Content-Length: 0. >>> . >>> >>> >>> U +0.400706 yy.yy.yy.146:63610 ->      xx.xx.xx.51:5060 >>> REGISTER sip:register.domain.com SIP/2.0. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. >>> Max-Forwards: 70. >>> >>> >>> >>> Contact:<sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>. >>> To: "Test Ast"<sip:support1@register.domain.com>. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=ba705453. >>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >>> CSeq: 2 REGISTER. >>> Expires: 3600. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>> SUBSCRIBE, INFO. >>> User-Agent: eyeBeam release 1102q stamp 51814. >>> Authorization: Digest >>> >>> >>> >>> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. >>> Content-Length: 0. >>> . >>> >>> >>> U +0.005302 xx.xx.xx.51:5060 ->      yy.yy.yy.146:63610 >>> SIP/2.0 401 Unauthorized. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. >>> To: "Test >>> >>> >>> Ast"<sip:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. >>> From: "Test Ast"<sip:support1@register.domain.com>;tag=ba705453. >>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >>> CSeq: 2 REGISTER. >>> WWW-Authenticate: Digest realm="domain.com", >>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >>> Server: kamailio (3.2.1 (i386/linux)). >>> Content-Length: 0. >>> . >>> >>> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla >>> &lt;miconda(a)gmail.com&gt;      wrote: >>>> >>>> Hello, >>>> >>>> I need the entire flow for registration, including the 401 reply and >>>> the >>>> following REGISTER request. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 1/3/12 5:02 PM, Ali Jawad wrote: >>>>> >>>>> Hi >>>>> Please see the ngrep below, please note that if I use in the db >>>>> register.domain.com and generate a hash against it for HA1 it >>>>> works,but then the user cant logon to register2.domain.com >>>>> >>>>> >>>>> U +10.630576 xx.yy.yy.yy:20020 ->        xx.xx.xx.xx:5060 >>>>> REGISTER sip:register.domain SIP/2.0. >>>>> Via: SIP/2.0/UDP >>>>> >>>>> >>>>> >>>>> >>>>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >>>>> Max-Forwards: 70. >>>>> >>>>> >>>>> >>>>> >>>>> Contact:<sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp>. >>>>> To: "Test Ast"<sip:support1@register.domain>. >>>>> From: "Test Ast"<sip:support1@register.domain>;tag=976bb004. >>>>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >>>>> CSeq: 1 REGISTER. >>>>> Expires: 3600. >>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>>>> SUBSCRIBE, INFO. >>>>> User-Agent: eyeBeam release 1102q stamp 51814. >>>>> Content-Length: 0. >>>>> >>>>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >>>>> &lt;miconda(a)gmail.com&gt;        wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>>>>> >>>>>>> Hi Daniel >>>>>>> >>>>>>> Please see >>>>>>> >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:184]: allocate 8 bytes >>>>>>> for >>>>>>> rows >>>>>>> at >>>>>>> 0xb7b78d74 >>>>>>>  5(18649) DEBUG:<core>          [db_row.c:119]: allocate 20 bytes >>>>>>> for >>>>>>> row >>>>>>> values at 0xb7b78dac >>>>>>>  5(18649) DEBUG:<core>          [db_val.c:117]: converting STRING >>>>>>> [6f966cd9c628f14cdc20172f96a4d065] >>>>>>>  5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>>> '6f95e6235edca0b7765042ef119fd83b' >>>>>>>  5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>>>>> failed >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:81]: freeing 1 columns >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:85]: freeing >>>>>>> RES_NAMES[0] at >>>>>>> 0xb7b78d3c >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:94]: freeing result >>>>>>> names at >>>>>>> 0xb7b78bfc >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:99]: freeing result >>>>>>> types at >>>>>>> 0xb7b78c64 >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:54]: freeing 1 rows >>>>>>>  5(18649) DEBUG:<core>          [db_row.c:97]: freeing row values >>>>>>> at >>>>>>> 0xb7b78dac >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:62]: freeing rows at >>>>>>> 0xb7b78d74 >>>>>>>  5(18649) DEBUG:<core>          [db_res.c:136]: freeing result >>>>>>> set at >>>>>>> 0xb7b78bb0 >>>>>>>  5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>>>>> realm='nymgo.com' >>>>>>>  5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>>>>> Digest realm="domain.com", >>>>>>> nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>>>>> ' >>>>>>> >>>>>>> I rebuilt the hashes against domain.com and then tried to connect >>>>>>> to >>>>>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all >>>>>>> of >>>>>>> the having >>>>>>> >>>>>>> >>>>>>> # ----- auth_db params ----- >>>>>>> #!ifdef WITH_AUTH >>>>>>> modparam("auth_db", "db_url", DBURL) >>>>>>> modparam("auth_db", "calculate_ha1", 0  ) >>>>>>> modparam("auth_db", "password_column", "ha1") >>>>>>> modparam("auth_db", "load_credentials", "") >>>>>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>>>>> >>>>>>> And in the routing process : >>>>>>> >>>>>>>    if (!www_authorize("domain.com", "subscriber")) >>>>>>>                 { >>>>>>> >>>>>>>                         www_challenge("domain.com", "0"); >>>>>>>                         exit; >>>>>>>                 } >>>>>>> >>>>>>> >>>>>>> +++++++++++++ >>>>>>> >>>>>>> My point is that the hashes are caculated from user:doman:pwd >>>>>>> which >>>>>>> are extracted from the SIP packet and in this case the domains >>>>>>> are >>>>>>> sip1,sip2,sip3 while the hashes stored in the database are >>>>>>> generated >>>>>>> against domain.com >>>>>>> >>>>>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I >>>>>>> have >>>>>>> to >>>>>>> set the domain/realm in the config file ? >>>>>> >>>>>> >>>>>> the first parameter in www_authorize and www_challenge functions >>>>>> is >>>>>> the >>>>>> realm and it is used to build the digest response. >>>>>> >>>>>> Is your phone putting user@domain in authorization header? Can you >>>>>> paste >>>>>> here the ngrep of registration? >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>>> I might be wrong....thanks for the help so far. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>>>>> &lt;miconda(a)gmail.com&gt;          wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>>>>> >>>>>>>>> Hi Daniel >>>>>>>>> This certainly makes sense, I will try it in a few mins, but >>>>>>>>> what >>>>>>>>> I >>>>>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>>>>> www_authenticate is executed and it shows HA comparison failed, >>>>>>>>> if >>>>>>>>> I >>>>>>>>> do use domain.com instead of $fd and use $domain.com in db >>>>>>>>> domain >>>>>>>>> field and build HA1 filed based on that, wont Kamailio still >>>>>>>>> try >>>>>>>>> to >>>>>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>>>>> where >>>>>>>>> domain is fed in to the hash function from the header of the >>>>>>>>> SIP >>>>>>>>> packet ? >>>>>>>> >>>>>>>> >>>>>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just >>>>>>>> common >>>>>>>> practice >>>>>>>> to use the domain as realm, since realm should be a unique token >>>>>>>> to >>>>>>>> identify >>>>>>>> the service, but it can  be any random string. realm is given as >>>>>>>> parameter >>>>>>>> to auth functions in kamailio.cfg >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniel >>>>>>>> >>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>>>>> &lt;miconda(a)gmail.com&gt;            wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>>>>> authentication >>>>>>>>>> function instead of $fd. Also build ha1 and ha1b with >>>>>>>>>> domain.com >>>>>>>>>> and >>>>>>>>>> then >>>>>>>>>> you are safe no matter which sip server is used. >>>>>>>>>> >>>>>>>>>> Of course you can build the realm by striping first token >>>>>>>>>> before >>>>>>>>>> '.' >>>>>>>>>> in >>>>>>>>>> $fd >>>>>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>>>>> sense >>>>>>>>>> since >>>>>>>>>> it should be always domain.com >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Daniel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> After some research it seems to me that the only way to >>>>>>>>>>> achieve >>>>>>>>>>> this >>>>>>>>>>> is to "try" and change how hashing is done in the source >>>>>>>>>>> code, a >>>>>>>>>>> little bit too ambitious for me, and it means I will have >>>>>>>>>>> loads >>>>>>>>>>> of >>>>>>>>>>> problems each time an upgrade is released. >>>>>>>>>>> >>>>>>>>>>> Or >>>>>>>>>>> >>>>>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>>>>> something >>>>>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>>>>> able >>>>>>>>>>> to >>>>>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>>>>> >>>>>>>>>>> Any input please ? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>>>>> Jawad&lt;ali.jawad(a)splendor.net&gt; >>>>>>>>>>>  wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>>>>> registrations, >>>>>>>>>>>> one >>>>>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>>>>> registrations. >>>>>>>>>>>> Each >>>>>>>>>>>> of those devices connects to it's perspective kamailio >>>>>>>>>>>> server >>>>>>>>>>>> >>>>>>>>>>>> sip1.domain.com >>>>>>>>>>>> sip2.domain.com >>>>>>>>>>>> sip3.domain.com >>>>>>>>>>>> >>>>>>>>>>>> All 3 Kamailio servers share the same database, and users >>>>>>>>>>>> can >>>>>>>>>>>> use >>>>>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>>>>> use >>>>>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>>>>> database. >>>>>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>>>>> want >>>>>>>>>>>> to >>>>>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>>>>> basically >>>>>>>>>>>> because the db domain entry from which the hash is created >>>>>>>>>>>> is >>>>>>>>>>>> sip1.domain.com and stored in the db, while the user >>>>>>>>>>>> connects >>>>>>>>>>>> from >>>>>>>>>>>> to >>>>>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>>>>> >>>>>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>>>>> Hash >>>>>>>>>>>> generation ? Any other option that allows me to do the above >>>>>>>>>>>> ? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>> >>>> -- >>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> > -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda