මේ පැකේජ නිර්මාණය කරන අය ඒවා තමන්ගෙම කියලා සඳහන් කරන්න පාවිච්චි කරන්නේ Digital signing කියන ක්‍රමවේදය. මෙතනදි පාවිච්චි වෙන්නෙ PKI (Public Key infrastructure) කියන ආරක්ෂක තාක්ෂණය. සාමාන්‍යයෙන් GNU ආශ්‍රිත වැඩ වලදි මේක හැඳින්වෙන්නේ GPG (GNU Privacy Guard) විදියට. PKI වලදි ධූරාවලික ආකෘතියක් භාවිතා කරනවා. GPG වලදි භාවිතා වෙන්නේ වෙබ් (ජාලගත) ආකෘතියක්. මේ ආකෘතිය යටතේ Key වර්ග දෙකක් තියෙනවා. එකක් ප්‍රසිද්ධියේ ලබා ගන්න පුලුවන් Public Key එක. අනිත් එක භාවිත කරන්නා ලඟ ප්‍රවේශමෙන් තබා ගන්න ඕන වෙන් Private Key එක.

Apt-get update මගින් පැකේජ බාගත කරද්දී ඒවා අව්‍යාජ ද කියලා බලන්නේ ඒ පැකේජ වල Public Key එක ආධාරයෙන්. සමහර වෙලාවට මේ Key ආධාරයෙන් කරන පරීක්ෂා කිරීම් වැරදිනම් බාගත කරන එක නවත්තනවා. පහල තියෙන message එකට සමාන ආකාරයේ message එකක් දර්ශනය කරන්න පුලුවන්.

W: GPG error: http://archive.canonical.com intrepid Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key

මේ ප්‍රශ්නය හදාගන්න අපිට පහල විධාන ලබා දීමෙන් කරගන්න පුලුවන්.

sudo apt-get clean

sudo mv /var/lib/apt/lists /var/lib/apt/lists.old

sudo mkdir -p /var/lib/apt/lists/partial

sudo apt-get clean

sudo apt-get update

/var/lib/apt/lists කියන ඩිරෙක්ටරිය ඇතුලේ තියෙන්නේ පැකේජ අඩංගු රිපෝසිටරි (repository) වල නම් සඳහන් ගොනු ලැයිස්තුවක්. මේ ගොනුවක් cat කරලා බැලුවොත් අපිට දකින්න පුලුවන් update අවශ්‍ය වෙන පැකේජ සහ ඒවාගේ version වල ලැයිස්තුවක් (තවත් විස්තර සහිතව) ඇතුලත් වෙලා තියෙනවා කියලා. අපි මේ ඩිරෙක්ටරිය වෙනස් කිරීමෙන් හඟවන්නේ මේවා නැවත සකස් කර ගන්න කියලා. apt-get මගින් එවිට ඒ ගොනු නැවත සාදාගන්නවා.

Apt-get clean මගින් මෙතෙක් කල් බාගත කරලා තියෙන පැකේජ කෑෂ් එකෙන් මකලා දානවා. එතකොට මුල ඉඳන් නැවත අදාල පැකේජ බාගත කරගන්නවා. මුල ඉඳන් බාගත කිරීමේදී කලින් ඇති වෙලා තිබුන අක්‍රමිකතා මැකිලා යන්න පුලුවන්.

Bibliography:

How to fix the Ubuntu GPG Error BADSIG

DNS query එකක් යැවෙන්නේ UDP හරහා. මේ ප්‍රොටෝකෝලයට අනුව එක් පැකට් එකක් (UDP වලදි පැකට් එකක් හඳුන්වන්නේ Datagram එකක් ලෙසට) බයිට් 512ට වඩා වැඩි වෙන්න බැහැ.

ඊළඟ සැලකිය යුතු කාරණයෙ වෙන්නේ DNS සේවාවේ ගුණාත්මක භාවය. අපි යවන DNS query එක දිග වැඩි වුනොත් error correction වගේ ගොඩක් ක්‍රියාවලින් සිදු කරන්න වෙනවා සැලකිය යුතු මට්ටමේ සේවාවකට. ඒක නිසා මුල් කාලයේදී ගත්ත එක තීරණයක් වුනේ DNS query එකක් එක datagram එකකට වඩා දිග වෙන්න බෑ කියලා.

IPv4 යටතේ (මේ යටතේ IP address එකක් බිට් 32ක ඉඩක් ගන්නවා. උදා : 10.16.108.25) මේ එක datagram එකක් තුලට ඔබ්බවන්න පුලුවන් IP address ප්‍රමාණය වුනේ 13. එතකොට බයිට් 450ට වඩා අඩු ගණනකට එනවා. 512න් ඉතුරු ඉඩ ප්‍රොටෝකෝලයේ අනෙකුත් දත්ත තැන්පත් කරන්න අවශ්‍ය වෙනවා.

මේ හේතුව නිසා තමයි මුලදී Root සර්වර් 13කට එකඟතාවයක් ඇති වෙලා තියෙන්නේ. නමුත් අනාගතයේදී (විශේෂයෙන් IPv6  සම්මත වලදී) මේ ගණන වෙනස් වෙන්න පුලුවන්.

සැලකිය යුතු අනෙක් කාරණය වෙන්නේ භෞතිකව සර්වර් 13ට වඩා තිබීම. IP address 13 යටතේ සර්වර 200කට ආසන්න ප්‍රමාණයක් ලොව පුරාම විසිරිලා තියෙනවා. මේ නිසා වඩාත් ගුණාත්මක වගේම විශ්වාසනීය සේවාවක් සපයන්න මේ සර්වර් වලට පුලුවන්.

එකම IP address එක යටතේ වෙන වෙනස් භෞතික සර්වර් තියෙන්නේ anycast කියන තාක්ෂණය භාවිතා කරලා. මේ යටතේ IP address එකක් සඳහා request එකක් යැවූ විට ඒ සඳහා ළඟම තියෙන භෞතික සර්වරය තෝරාගෙන ඒකට යොමු කෙරෙනවා. මේ නිසා සර්වරයට සිදු කල යුතු වැඩ ප්‍රමාණය ලොව වටාම බෙදා හරින්න පුලුවන් වෙලා තියෙනවා.

1. බ්‍රව්සරයේ address bar එක තුල අප විසින් http://blog.example.lk ලෙස වෙබ් ලිපිනය සඳහන් කරනවා.
   • දැන් මෙම ලිපිනය IP address එකක් බවට පත් කල යුතුයි. මේ සඳහා මුලින්ම සේවාග්‍රාහකයා (client) ළඟ තිබෙන ගොනුවේ (hosts ගොනුව) මෙම ඩොමේනය තිබෙනවාදැයි සොය බලනවා.
   • එම ඩොමේනය යටතේ ඇතුලත් කිරීම තිබෙනවානම් DNS සඳහා යොමු වෙන්නේ නැහැ.
   • එසේ නැතිනම් ඉන්පසුව DNS සඳහා යොමු වෙනවා.
2. අපට අන්තර්ජාල සබඳතාවය ලබා දෙන සේවාදායකයා (ISP) මගින් එම සබඳතාවය සඳහා භාවිතා කල යුතු DNS සර්වරයේ IP address එක අපට ලබා දිය යුතුයි.
   • ඔබ සිටින්නේ LAN එකක් තුල නම් සාමාන්‍යයෙන් ඔබට එය තුල private static IP එකක් ලැබෙනවා. මෙම IP එක configure කරන විට අදාල DNS තොරතුරු ලබා දිය යුතුයි.
   • අපි සාමාන්‍යයෙන් භාවිතා කරන Broadband අන්තර්ජාල සේවාවන් වලදී අපට Static IP ලැබෙන්නේ නැහැ. අපට IP address එකක් ලැබෙන්නේ DHCP (Dynamic Host Configuration Protocol) නැමැති ක්‍රියාවලියක් තුලින්. සාමාන්‍යයෙන් කෙරෙන්නේ එලෙස dynamic IP address එකක් ලබා දෙන අවස්ථාවේදීම DNS IP address ද ඒ සමගම ලබා දීමයි.
3. එසේ ලබා දී ඇති DNS සර්වරය වෙත මෙම ඩොමේනයේ IP address එක ඉල්ලා query එකක් සිදු කෙරෙනවා. මෙම request එක යැවෙන්නේ UDP හරහා (අපි සාමාන්‍ය HTTP request යවන්නේ TCP හරහා).
   • මේ යැවෙන request එක වර්ග දෙකකින් එකක් වෙන්න පුලුවන්.
     • Recursive
     • Iterative (Non recursive)
   • සාමාන්‍යයෙන් මෙතනදි යැවෙන්නේ recursive request එකක්.
4. එම DNS සර්වරය example.lk (හෝ blog.example.lk සඳහා) authoritative නම් එය තුල මෙම ඩොමේනයට අදාල IP address එක තිබෙනවා. එම නිසා අදාල IP address එකට අදාල A Resource Record එක පිලිතුර වශයෙන් එවනවා (Resource Records පිළිබඳව පසුව සටහනකින් බලාපොරොත්තු වන්න). එවිට සේවාග්‍රාහකයාට පුලුවන් එමගින් IP address එක සොයාගෙන එම IP address එකට අවශ්‍ය request එක ඉදිරිපත් කරන්න (උදා: වෙබ් නම් GET හෝ POST ලෙස).
   • හුඟක් වෙලාවට වෙන්නේ මේ සර්වර් එක Caching සර්වර් එකක් වෙන එක. ඒකෙන් කරන්නේ තමන් දැනට කෑෂ් කර ගත්ත ඇතුලත් කර ගැනීම් වල මේ blog.example.lk IP address එක තියෙනවද කියලා බලන එක.
   • එහෙම ඇතුලත් කර ගැනීමක් කෑෂ් එකේ නැත්තන් ඊළඟට blog.example.lk සඳහා request එකක් root සර්වර් වෙතට යැවෙනවා. මේ root සර්වර් 13ම IP address DNS සර්වරයක තියෙනවා. මුලින්ම තියෙන address එකට request යැවෙනවා. ඒක වැඩ නැත්තන් ඊළඟ එක, ඔය විදියට තමයි root සර්වර සම්බන්ධ කර ගන්නේ.
   • මේ සම්බන්ධ කර ගැනීම හුඟක් වෙලාවට iterative වෙන්න පුලුවන්. නමුත් recursive විදියටත් සම්බන්ධ කර ගැනීම් සිදුවෙනවා.
5. පිලිතුරු දෙන root සර්වරය ළඟ blog.example.lk වල IP address නැහැ (කෑෂ් කිරීම සිදු කරන්නේ නැත්තන්). ඒත් මම කලින් සඳහන් කලා වගේ root සර්වර් ලඟ තියෙනවා. Root සර්වර් සම්බන්ධතාවය recursive නම් root සර්වරය විසින්ම .lk DNS සර්වරය සම්බන්ධ කර ගැනීම සිදු කරනවා. සම්බන්ධතාවය iterative නම් අදාල .lk DNS සර්වර්යේ IP address එක පිලිතුර ලෙස එවනවා. එවිට ඒ සර්වරයට request යවන්න ඕනෙ DNS caching සර්වරය මගින්.
6. .lk සර්වරය මගින් example.lk හි IP address එක එවනවා.
7. example.lk සර්වරය සම්බන්ධ කර ගැනීම මගින් blog.example.lk හි IP address එක ලබාගන්නවා. මෙය බොහෝ වෙලාවට example.lk හි IP address එකම තමයි.
8. Caching සර්වරය මගින් මේ IP address එක අපේ පරිගණකය වෙත එවනවා. ඉන්පසුව තමයි බ්‍රව්සරය මගින් ඒ IP address එකේ port 80ට (වෙනත් port එක යොදා ඇත්නම් ඒකට) HTTP GET request එකක් යවන්නේ.

අන්තර්ජාලයේ සිදුවන DNS traffic වලින් 95%ටත් වඩා තියෙන්නේ UDP traffic. ඒ කියන්නේ වැඩිපුරම තියෙන්නෙ requests. පිලිතුර දීම් සිදුවෙන්නේ TCP හරහා.

සියළුම request යැවෙන්නේ http://blog.example.lk සඳහා නොවේ. ඒ වෙනුවට මේ ලිපිනයේ අගට තිතක් එකතු කරලා FQDN එක සඳහා request සිදු කෙරෙනවා (http://blog.exmaple.lk.). තිත සඳහා authoritative වෙන්නේ Root සර්වර්. ඒකයි හොයාගන්න බැරි වුනාම root සර්වර් වෙත request යැවෙන්නේ.

FQDN එක අපි සාමාන්‍යයෙන් ලිනක්ස් වලදි හඳුන්වන absolute path එක වගේ. තිත නොමැතිව තියෙන වෙබ් ලිපින හඳුන්වන්නේ relative domain names/Partially qualified domain names කියලා (මේ ගැන කියලා දුන්න අනුරංගට ස්තුතියි).

අන්තර්ජාල භාවිතය තුල IP address වැදගත් වෙන්නෙ ඉහත කියපු දේට. අන්තර්ජාලය තුල ඇති පරිගණක අනන්‍ය වූ විදියට හඳුනාගැනීමට (NATting, Proxy, Shared Hosting වගේ කාරණා නිසා මේ කියන තරම් ම මේක සරල නෑ). අපි වෙබ් අඩවියකට යනවා කියන්නේ අන්තර්ජාලය තුල පිහිටුවලා තියෙන පරිගණකයකින් වෙබ් සේවාවක් ඉල්ලනවා කියන එක. මේ සේවාවට අපිට අවශ්‍ය දත්ත දෙකක් තියෙනවා.

• අදාල වෙබ් සර්වරයේ IP address එක
• අදාල වෙබ් සේවාව ක්‍රියාත්මක වෙන Port එක (මේක සම්මතයක් විදියට 80 ලෙස සැලකෙනවා. නමුත් වෙනස් වීමට කිසිදු සීමාවක් නෑ)

නමුත් අපි කවදාවත් IP address එකක් ටයිප් කරලා වෙබ් අඩවියකට යන්නේ නැහැ. අපි IP address වෙනුවට භාවිතා කරන්නේ ඩොමේන් නාම. බ්‍රව්සරයේ http://wordpress.com ලෙස ටයිප් කරනවා මිසක් http://74.200.247.60 ලෙස ටයිප් කරන්නේ නැහැ. ඇත්තටම ඩොමේන් නාම භාවිතා වෙන්නේ මේ හේතුව නිසා. අපිට wordpress.com කියන එක මතක තබාගෙන භාවිත කරන්න පහසුයි අංක ටිකකට වඩා.

නමුත් ඩොමේන් නාමයක් යොදාගෙන පරිගණකයකට කතා කරන්න බැහැ. එයට IP address අවශ්‍යමයි. එසේනම් කවුරුන් හෝ අප මේ ඇතුලත් කරන ඩොමේන් නාමය IP address බවට පරිවර්තනය කල යුතුයි. මේ ක්‍රියාවලිය ක්‍රම දෙකකින් සිදු වෙන්න පුලුවන්.

• ඩොමේන් නාමයට අදාල IP address එක සම්බන්ධ කරපු ගොනුවක් අපගේ පරිගණකයේ තබාගෙන ඒ ගොනුව ආශ්‍රයෙන් ඩොමේන් නාමය -> IP address කල හැකියි.
  • ලිනක්ස් පද්ධති තුලදී මෙම ගොනුව තියෙන්නේ /etc/hosts ලෙසට
  • වින්ඩෝස් තුලදී මෙය ඇත්තේ c:\Windows\System32\drivers\etc\hosts ලෙසට
• වෙනත් සර්වරයක් මගින් එවැනි ගොනුවක් කළමනාකරණය කර ගනිමින් අප ඉල්ලූ විට අපට IP address ලබා දිය හැකියි.
  • DNS – Domain Name Service/Server ලෙස හැඳින්වෙන්නේ මෙයයි.

අන්තර්ජාලයේ කොඳුනාරටිය විදියට ඩොමේන නාම සේවාව (Domain Name Service) හැඳින්වීමට පුලුවන්. මෙම සේවාව නොමැති වූවොත් ඕනෑම අන්තර්ජාල සේවාවක් (වෙබ්, ඊමේල්, චැට් ආදී) ලබා ගැනීමට IP address මතක තබාගැනීමට සිදු වෙනවා. Shared Server වලින් දැනට අපට ලැබෙන ලාබ දායි සේවාවත් නැතිවී යන්න පුලුවන් (Name Based Virtual Hosting සඳහා DNS අවශ්‍යයි).

Root සර්වර්

DNS පද්ධතිය තියෙන්නේ hierarchical ආකාරයකට. ඒ කියන්නේ එක මූලයකින් බෙදි බෙදී පහළට යන ධුරාවලියක් විදියට. ඇත්තටම මේ පද්ධතියේ එක මූලයක් වෙනුවට මූලයේ කොටස් 13ක් තිබෙනවා. මේවා හැඳින්වෙන්නේ Root server විදියට. මේ 13 පිළිවෙලින් A සිට M දක්වා නම් කර තිබෙනවා.

Root සර්වර් 13ක් වෙන්නේ මුලින් UDP වල තිබුන පොඩි අකාර්යක්ෂමතාවයක් නිසා. UDP packet එකක දිග බයිට් 512 වඩා අඩු වෙන්න ඕනෙ කියන අවශ්‍යතාවය නිසා පවත්වාගෙන යන්න පුලුවන් Root සර්වර් ප්‍රමාණය 13ට සීමා වුනා. හැබැයි දැන් මෙම සර්වර් 13ට වඩා තියෙනවා. ඒත් ඒ තියෙන්නේ anycast කරපු ආකාරයට. ඒ කියන්නේ තවමත් Root සර්වර් IP තියෙන්නේ 13යි. නමුත් සමහර Root සර්වර් mirror කිරීම මගින් ලෝකය පුරා බෙදා හැරලා තියෙනවා. එකක් අකර්මණ්‍ය වුනොත් අනිත් ඒවගෙන් වැඩ කරගෙන යන්න පුලුවන් විදියට. මෙයින් mirror කරපු Root සර්වරයක් ලංකාවෙත් තිබෙනවා.

Root සර්වර් ගැන වැඩිදුර විස්තර දැන ගන්න මේ වෙබ් අඩවියට ගිහින් බලන්න.

Root සර්වරයට තියෙන හඳුනා ගැනීම වෙන්නේ “.” හෙවත් තිත. සාමාන්‍යයෙන් ඩොමේනයක Fully Qualified Domain Name (FQDN) යනුවෙන් හඳුන්වන්නේ මෙම තිතත් එක්කම තියෙන ඩොමේන නාමය.

උදා: http://chamiladealwis.com.   (තිත අන්තිමටම)

මෙම Root සර්වරයන් තුල සියළුම Top Level Domain (TLD) සඳහා DNS සර්වරයන්ගේ IP address සටහන් වී තිබෙනවා. ඒ නිසා ඕනෑම කෙනෙකුට Root සර්වරයකින් අදාල TLD එකක IP address එක සොයාගත හැකියි. TLD වර්ග දෙකක් තිබෙනවා.

1. gTLD – Generic TLD
   • .com
   • .org
   • .info
   • .gov
   • .biz
   • .aero ආදී වශයෙන්
2. ccTLD – Country Code TLD
   • .lk
   • .in
   • .jp
   • .ly ආදී වශයෙන් රටවල් වලට ලබා දී ඇති ඩොමේන නාම

මේ එක් එක් TLD යටතේ අප සාමාන්‍යයෙන් දන්නා ඩොමේන ක්‍රියාත්මක වනවා.

උදා:

• google.com
• amazon.com
• ac.lk
• digit.lk
• bit.ly (අහලා පුරුදුයි වගේ නේ)
• wordpress.org
• blogger.com

මේ නිසා අපට Root සර්වරයකින් ඇහුවොත් ac.lk හි IP address එක, එය එතනින් ලබා ගන්න බැහැ. ඒ වෙනුවට Root සර්වරය විසින් අපව .lk DNS සර්වරය වෙත යැවෙනවා. එතනින් අපට ලබා ගන්න පුලුවන් ac.lk සඳහා IP address එක.

මෙම ඩොමේන යටතේ උප ඩොමේන (sub domain) පවතින්න පුලුවන්. උදාහරණයකට cmb.ac.lk කියන්නේ කොළඹ විශ්ව විද්‍යාලයට ලබා දී තිබෙන උප ඩොමේනය. cmb.ac.lk සඳහා IP address ලබා ගන්න ඕනෙ කාගෙන් ද?

Zones සහ ඩොමේන

මෙම Root Server යටතේ විවිධ zone අර්ථ දක්වා තිබෙනවා. සාමාන්‍යයෙන් එක zone එකක් පාලනය කරන්නේ එක DNS සර්වරයක් මගින්. එක් zone එකක් තුල එකක් හෝ වැඩි ගණනක ඩොමේන තිබෙන්නට පුලුවන්. මෙය ටිකක් පැටලිලි සහගතයි.

(පින්තූරය ගත්තේ Wikipedia වලින්)

කළු ඉරකින් වට කර දක්වා තියෙන්නේ Zones. එක Zone එකක් දුවන්නේ එක DNS සර්වරයකින්. එකම DNS සර්වරයකින් ඩොමේන කිහිපයක් දුවවන්න පුලුවන්. ඉහත රූපයේ .org ඩොමේනය යටතේ තිබන සියළුම ඩොමේන දුවවන්නේ එකම Zone එකක් තුල නිසා එකDNS සර්වරයකින් (සැබෑ ලෝකයේදී මෙය මෙසේ නොවිය යුතුයි).

DNS සර්වර් වර්ග

ප්‍රධාන වශයෙන් DNS සර්වර් වර්ග දෙකකට බෙදන්න පුලුවන්.

Authoritative Server

DNS සර්වරයක් මේ වර්ගයට අයිති වෙන්නේ එය යටතේ තියෙන ඩොමේන සඳහා පිළිතුරු ලබා දීමට හැකි නම් විතරයි. ඒ කියන්නේ ඒ සර්වරය තුලින් ලබා දෙන පිළිතුරු නිපදවන්නේ එය තුලමයි. හැම zone එකකටම අනිවාර්යයෙන් authoritative DNS සර්වරයක් තිබිය යුතුයි. අදාල zone එකේ ඩොමේන පිලිබඳ තොරතුරු A RR විදියට ගබඩා කර ගැනීම එය විසින් සිදු කරන්න ඕනෙ. ඊට අමතරව එම zone එක තුල zone එකක් වෙනත් Name සර්වරයකට delegate කර ඇත්නම් ඒ Name සර්වර ඇතුලත් කිරීම් ගබඩා කරගන්නත් ඕනෙ.

මෙම සර්වර වර්ග දෙකක් තියෙනවා.

1. Primary DNS

   • මෙය තමයි ප්‍රධාන DNS සර්වරය. DNS ඇතුලත් කිරීම් අලුතින් සිදු කරන්නෙත්, වෙනස් කම් කරන්නෙත්, මකා දැමීම් කරන්නෙත් මෙය තුල. ක්‍රියාත්මක වන අවස්ථාවලදී query සඳහා පිලිතුරු දෙන්නේ මෙය විසින්.

2. Secondary DNS

   • මේ සර්වරය තියෙන්නේ Primary සර්වරයට අමතර දෙයක් විදියට. මෙහි කිසිම වෙනස්කමක් අපි සිදු කරන්නේ නැහැ. එය කරන්නේ කාලයෙන් කාලයට Primary DNS සර්වරයෙන් zone transfer ක්‍රියාවලිය මගින් DNS ඇතුලත් කිරීම් පිටපත් කර ගැනීම.
   • DNS සේවාවේ තියෙන වැදගත් කම නිසා තමයි secondary සර්වරයක් තියෙන්නේ. Primary සර්වරය අකර්මණ්‍ය වුනොත් සේවාව ලබා දෙන්න වෙන්නේ secondary සර්වරයට

Caching Servers

මේ සර්වර් වර්ගයේදී තමන්ට ලැබුන query එකක් වෙනුවෙන් වෙනත් සර්වරයකට කතා කරලා පිලිතුර ලබා දෙනවා. ඒ ලබා දෙන ගමන්ම එම පිලිතුර සර්වරය තුල කෑෂ් කර ගන්නවා. එම නිසා වාසි දෙකක් සිදු වෙනවා.

• නැවත query එකක් ආවොත් තමන්ගේ කෑෂ් එකෙන් පිලිතුර දීමට පුලුවන්.
• සේවාග්‍රාහකයින් විසින් කරන්න ඕනෙ කෑෂ් සර්වරයකට query එක යැවීම විතරයි. එම සර්වරයට පිලිතුරු දීමට බැරිනම් root සර්වරයන් හා recursive request මගින් (මේවා ඉදිරි සටහනකින් පැහැදිලි කරන්නම්) අදාල පිලිතුර සොයලා දෙනවා. මේ නිසා සේවාග්‍රාහක වැඩසටහන් අනවශ්‍ය ලෙස සංකීර්ණ වීම නවතිනවා. සේවාග්‍රාහකයා කල යුත්තේ අවශ්‍ය කෑෂ් සර්වරයේ IP address ගබඩා කර ගැනීම පමණයි.

සාමාන්‍යයෙන් කෑෂ් සර්වර පවත්වාගෙන යන්නේ ISP විසින්. DNS Propagation කාලයට හේතු වෙන්නෙත් මේ කෑෂ් සර්වර්.

============================================================================================

අපි බ්‍රව්සරයේ ඩොමේන නාමයක් ඇතුලත් කලාම සිදුවන මුල්ම දේ තමයි මේ ඩොමේන නාමය IP address එකක් බවට පරිවර්තනය කිරීම. මේ සඳහා අපි නොහිතන දුරකට ක්‍රියාවලියක් සිදුවෙනවා. මී ළඟ සටහනින් එය දක්වන්නම්.

OpenID පිළිබඳ ලිපි පෙලේ අවසාන කොටස විදියට මෙම සටහන ලියැවෙනවා.

OpenID සේවාදායකයින් ළඟ ලියාපදිංචි වුනාට පස්සේ අපිට ලැබෙන්නේ URL එකක්. එය සාමාන්‍යයෙන් ඔවුන්ගේ ඩොමේන් නාමය ඇතුලත් ලිපිනයක්. එම ලිපිනයේ සඳහන් තොරතුරු වලට අනුව තමයි අදාල OpenID සර්වරය තෝරා ගෙන අපව authenticate කර ගන්නේ. OpenID යොදාගෙන බ්ලොග් අඩවියක ප්‍රතිචාර යොදා තිබෙන තැනක් මත click කලොත් අප දර්ශනය වෙන්නේ බොහෝ වෙලාවට ඒ සේවා දායකයින්ගේ පිටු.

නමුත් අපිට අපේ ඩොමේනයක් OpenID URL එක ලෙස භාවිත කිරීමේ හැකියාවත් තිබෙනවා. නමුත් එයට අපි විසින් OpenID සර්වරයක් කළමනාකරණය කල යුතු නෑ. ඒ වෙනුවට වෙනත් OpenID සේවාදායකයෙකුගේ සේවාවේ සර්වරයෙන් ඒ වැඩේ කර ගන්න පුලුවන්. මෙය OpenID භාෂාවෙන් හඳුන්වන්නේ delegation කියලා.

පලමුවෙන්ම OpenID සේවාදායකයෙකු ලඟ ලියා පදිංචි විය යුතුයි. මේ සඳහා ජනප්‍රිය සේවාදායකයින් පිළිබඳ කෙටි විස්තරයක් කලින් ලිපියක තිබෙනවා.

ඉන්පසු පහත කේත කොටස අපගේ වෙබ් අඩවියේ index පිටුවේ ඇති </header> ටැගයට උඩින් ඇතුලත් කල යුතුයි.

<link rel="openid.server" href="http://openidserverurl" />
<link rel="openid.delegate" href="http://openiddelegateurl" />

මෙහි දී openid.server හි href අගය සඳහා ඔබ ලියාපදිංචි වුන OpenID සේවාදායකයාගේ server URL එක ලබා දිය යුතුයි. openid.delegate හි href අගයට සේවාදායකයාගේ delegate URL එක ලබා දිය යුතුයි.

මෙම අගයන් ලබා ගැනීමට පහත ආකාරය අනුගමනය කරන්න පුලුවන්.

1. ඔබගේ OpenID සේවාදායකයා ලබා දුන් URL එකට බ්‍රව්සරයක් යොදාගෙන යන්න.
2. එහි Right Click කර View Page Source තෝරන්න.
3. ලැබෙන කේතය පරීක්ෂා කර බැලුවොත් ඉහත ටැග සොයා ගැනීමට පුලුවන්. ඒවාගේ href සඳහා ඇති අගයන් ලබා ගන්න පුලුවන්.

උදාහරණයකට මම භාවිතා කරන claimid.com URL එකේ පහත ටැග නිරීක්ෂණය කරන්න පුලුවන්.

<link rel="openid.server" href="https://openid.claimid.com/server" />
<link rel="openid.delegate" href="https://openid.claimid.com/chamila_dealwis" />

දැන් ඔබගේ පිටුව save කර සර්වරයට upload කරන්න.

OpenID භාවිතයේදී ඔබේ වෙබ් අඩවියේ URL එක ඇතුලත් කරන්න. Authenticate කර ගැනීම සිදුවන්නේ පරණ ආකාරයටම සේවාදායකයාගේ පිටුවේදීයි. ඒ සඳහා ඔබ අලුතින් පිටු සෑදීමක් අවශ්‍ය වන්නේ නැහැ.

අපි ‍නිර්මාණය කරන වෙබ් අඩවි තුල පරිශීලකයින් කළමනාකරණය බොහෝ වෙලාවට කරන්නේ බොහෝම ගතානුගතික විදියට. User table එකක් සාදගෙන අලුතින් එන හැම පරිශීලකයෙකුගේම තොරතුරු ඒ table එකේ සඳහන් කරගෙන සිටිනවා. ඇතුල් වීමට අවශ්‍ය වුන වෙලාවට SELECT query එකක් මගින් පරිශීලක නාමය (username) හා රහස් පදය (password) නිවැරදි දැයි බලනවා. ඉන්පසු Session අගයක් ලෙස එම අගයන් තබාගෙන logout වීමේදී එය අගයන් මකා දමනවා.

මේ සියලු දේ වෙනුවට OpenID මගින් පරිශීලකයින්ට ඇතුල් වීමට පහසු කම ලබා දුන්නොත් ප්‍රධාන වශයෙන් පහත වාසි ලබා ගන්න පුලුවන්.

• පරිශීලකයින්ට අලුතින් ලියාපදිංචි වීමට හෝ පෞද්ගලික තොරතුරු නැවත නැවතත් ලබාදීමට බල කිරීමට අවශ්‍ය නෑ.
• ලියාපදිංචි වීමේ form, ඒවා සඳහා validation ආදී කරදර වලින් මිදෙන්න පුලුවන්.
• අමතර user table එකක් බොහෝ වේලාවට අවශ්‍ය වන්නේ නෑ (නමුත් මෙය අවශ්‍යතාවය අනුව වෙනස් වෙන්න පුලුවන්).
• පරිශීලකයින්ගේ ‍තොරතුරු ගබඩා කර ගනිමින් වැඩි බරක් දරා සිටීමට අවශ්‍ය නෑ.
• SSL වැනි සංකීර්ණ ආරක්ෂාවන් ලබා දීමේ ක්‍රියාවලීන් වල බරක් දරා සිටින්න අවශ්‍ය නෑ. එය බොහෝ විට OpenID සේවා දායකයින් විසින්ම ලබා දෙනවා.

වෙබ් අඩවි වලින් ලබා දෙන සේවා භාවිතයට පරිශීලකයින් මැලි වන එක ප්‍රධාන හේතුවක් තමයි අලුතින් ලියා පදිංචි වීමේ කරදරය හා පෞද්ගලික තොරතුරු ලබා දීමට ඇති මැලිකම. OpenID භාවිතය මගින් පරිශීලකයින්ට වඩාත් පහසුවෙන් ඔබ ලබා දෙන සේවා පරිහරණය කරන්න පුලුවන්.

OpenID භාවිතයෙන් ඇතිවෙන්න පුලුවන් අවාසි කිහිපයක් පෙල ගස්සවන්න උත්සහ කෙරුවොත්,

• පරිශීලකයා මොහොතකට තමාගේ අඩවියෙන් පිටතට යැවෙනවා.
• භාවිතා කිරීමට හැකි පරිශීලකයින් ප්‍රමාණය පාලනය කිරීමට අමතර වෙහෙසක් ගැනීමට සිදු වෙනවා.

අප නිර්මාණය කරන වෙබ් අඩවියට OpenID පහසුකම ලබා දීම  පහසු කර ගැනීමට නිපදවුන plugin තිබෙනවා. CMS යොදාගෙන අඩවි නිර්මාණය ජනප්‍රිය වී ඇති නිසා මෙම CMS බොහෝමයකට අදාල OpenID plugin එක තිබෙනවා.

• Drupal
• Wordpress (OpenID)
• SPIP
• WebGUI
• MediaWiki
• DokuWiki
• phpBB
• PunBB

මෙහි සම්පූර්ණ ලැයිස්තුව මෙතනින් බලා ගන්න පුලුවන්. බොහෝ විට plugin එක ස්ථාපනය කරලා සරල settings කිහිපයක් හැදු ගමන්ම OpenID පහසුකම ලබා ගන්න පුලුවන්.

මෙම ලිපියෙන් බලාපොරොත්තු වන්නේ වෙනත් සේවාවක් ගැන විස්තර කරන්න. JanRain මගින් ලබා දෙන RPX now යොදා ගනිමින් ඉහත සඳහන් ලැයිස්තුවට අදාල නොවන අවස්ථා වලදී අපට OpenID පහසුකම ලබා ගන්න පුලුවන්. මෙතනදී OpenID යොදාගනිමින් login වීමේ පහසුකම (links) ලබා දෙන තැනේ ඉඳන්, අදාල OpenID සේවාදායකයින් සම්බන්ධ කරගෙන පරිශීලකයින් authenticate කර ගන්න තැන දක්වා ක්‍රියාවලිය RPX now විසින් ඉටු කර දෙනවා. ඉන්පසු එයින් නැවත එවන XML හෝ JSON response එකක් process කර ගැනීම අපට කල හැකියි. RPXnow සම්පූර්ණයෙන් නොමිලේ ලබා දෙන සේවයක් නොවුනත් OpenID සේවාදායකයින් කිහිප දෙනෙක් පමණක් සහය දක්වන ලෙස සැකසුනු නොමි‍ලේ සැපයෙන සේවාවකුත් ඔවුන් ලබා දෙනවා.

මෙහිදී සිදුවිය යුතු ක්‍රියාවලිය සරලව මෙහෙමයි.

1. මුලින්ම https://rpxnow.com/get වෙත යන්න. ලැබෙන පිටුවේ අපට ලබා ගත හැකි සේවා පැකේජ තිබෙනවා. හැකියාවක් තිබෙනවානම් වාණිජමය සේවාව ලබා ගන්න පුලුවන් . නමුත් මෙතනදි මම තෝරගන්නේ Basic යනුවෙන් තිබෙන නොමිලේ ලැබෙන සේවාව.
2. Sign Up මත click කලාම ඔබට login වීමට අවශ්‍ය යැයි පැව‍සෙනවා. ඔබට කැමති ගිණුම් වර්ගයක් තෝරාගෙන login වීමට පුලුවන්. මෙම login වීමේ ක්‍රියාවලිය නිරීක්ෂණය කරන්න. මේ RPX වෙතින් ඔබට ලැබෙන සේවයේ ආකාරයයි.
3. ඉන්පසු ඔබේ වෙබ් අඩවියේ විස්තර කිහිපයක් ඇතුල් කිරීමට අවශ්‍ය වෙනවා. Application Name වෙතට අවශ්‍ය හැඳින්වීමේ නාමයක් ලබා දෙන්න. Domains යටතේ ඔබේ වෙබ් අඩවිය ක්‍රියාත්මක වන domain ඇතුලත් කරන්න. මෙය එකක් හෝ කිහිපයක් වෙන්න පුලුවන්.
4. දැන් ලැබෙන පිටුවේ Configure Sign-on Widget මත click කරන්න. එහි ඔබේ අඩවියට ඇතුලත් වීමට භාවිතා කිරීමට ඉඩ දිය හැකි OpenID සේවා දායකයින් වම් පැත්තේ කොටුවට drag කර දමන්න. අවසන් වූ පසු Publish To Widget මත click කරන්න. Test Tool මත click කලහොත් ඔබේ තේරීමේ output එක බලා ගන්න පුලුවන්.
5. නැවත Application->Dashboard වෙත යන්න.
6. Quick Start Guide මත click කරන්න.

දැන් ඔබ RPXnow වෙතින් පැමිණෙන token එක යොදා ගනිමින් POST request එකක් සිදු කිරීමටත් ඉන්පසුව ලැබෙන පිළිතුර (XML|JSON) process කිරීමටත් server side පිටුවක් ලිවිය යුතුය.  මෙම පිටුව online web server එකක රැඳවිය යුතුයි. එම පිටුවේ සබැඳිය token_url ලෙස අප පසුව භාවිතයට ගන්නවා.

මෙම පිටුවෙන් සිදුවෙන දේ සාරංශයක් ලෙස ගත්තොත්,

1. Request එකෙන් token යනුවෙන් ඇති POST variable එකේ අගය ලබා ගත යුතුයි.
2. එම token එක හා ඔබගේ RPXnow API Key එක භාවිතා කරමින් https://rpxnow.com/api/v2/auth_info වෙත POST request එකක් සිදු කල යුතුයි.
3. පරිශීලකයා අවසරය දුන්නොත් මෙම ක්‍රියාවලිය අවසානයේ නැවත token_url වෙත ඔහුව යොමු කෙරෙනවා. එහිදී ඔබේ පිටුවට ඔහුගේ OpenID credentials ලැබෙනවා. එම credentials භාවිතය ඔබට ලැබෙන පිළිතුර process කිරීම සිදු කරන්න පුලුවන්.

RPXnow API Key එක ඔබට අනන්‍ය වුන එකක්. මෙය ඔබට Application->Dashboard වෙත ගොස් API key මත click කිරීමෙන් ලබා ගන්න පුලුවන්. මේ key එක වෙන කෙනෙක් අතට යවන්න එපා.

පහළ තිබෙන්නේ මෙම token_url පිටුව PHP යොදාගෙන implement කිරීමක්.

$token = $_POST['token'];

$curlOb = curl_init();
curl_setopt($curlOb, CURLOPT_URL,"https://rpxnow.com/api/v2/auth_info");
curl_setopt($curlOb, CURLOPT_POST, 1);
curl_setopt($curlOb, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curlOb, CURLOPT_POSTFIELDS, "apiKey=4xxxxxxxxxxxxxxxxxxxxxxxxxxxxxa3&token={$token}&format=xml");
$res = curl_exec ($curlOb);
curl_close ($curlOb);

$xml = simplexml_load_string($res);
$id = $xml->profile->identifier;
$display_name = $xml->profile->displayName;

මෙහිදී POST අගය $_POST['token'] යොදාගෙන $token variable එකට ලබා ගෙන තිබෙනවා. ඉන්පසු curl tool එක භාවිතා කරමින් https://rpxnow.com/api/v2/auth_info වෙත POST request එකක් යවා තිබෙනවා. මේ POST request එකේ variable තුනක් සඳහා අගයන් ලබාදී තිබෙනවා.

• apiKey – ඔබේ APIKey එක
• token – $_POST['token'] වෙතින් ලබා ගත් token අගය
• format – අපට ලැබෙන පිලිතුර XML format එකෙන් ලබා දෙන ලෙසට යවා තිබෙනවා. මෙම parameter එක භාවිතා නොකලොත් අපට ලැබෙන්නේ JSON ආකාරයේ පිළිතුරක්. මම PHP වලදී වැඩියෙන් දන්නේ XML process කරන්න නිසා මේ parameter එක භාවිතා කලා

මෙහිදී curl call එකින් ලැබෙන response එක අපි $res variable එකට ලබා ගෙන තිබෙනවා. දැන් එම variable එකේ තියෙන්නේ පහළ තියෙන ආකාරයේ XML ව්‍යුහයක්.

<?xml version='1.0' encoding='UTF-8'?>
<rsp stat='ok'>
<profile>
<displayName>
xxxxxxxxx
</displayName>
<email>
xxxxxxx@gmail.com
</email>
<identifier>

https://www.google.com/accounts/o8/id?id=Axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

</identifier>
<name>
<givenName>
xxxxx
</givenName>
<familyName>
xxxxxxx
</familyName>
<formatted>
xxxxxxxx
</formatted>
</name>
<preferredUsername>
xxxxxxxx
</preferredUsername>
<providerName>
Google
</providerName>
<verifiedEmail>
xxxxxxxxxxxxxxx
</verifiedEmail>
</profile>
</rsp>

මේ තිබෙන්නේ Google මගින් authenticate කර නැවත එවූ response එකක්. එක් එක් OpenID සේවාදායකයා මීට වඩා යන්තමින් වෙනස් පිළිතුරු එවන්න පුලුවන්. උදාහරණයකට සාමාන්‍ය OpenID සේවාදායකයෙක් email ලිපිනය එවන්නේ නෑ.

මෙතනදී අපිට පරිශීලකයෙක් හඳුනා ගැනීමටත්, ඔහුව ගබඩා කර ගැනීමටත් යොදා ගන්න පුලුවන් දත්ත දෙකක් තිබෙනවා.

• displayName
• identifier

Identifier ඒ පරිශිලකයාට අනන්‍ය වුන අගයක්. මේ නිසා මෙය ඔහුව හඳුනාගන්න භාවිතා කරන්න පුලුවන්. Display Name එක ඔහුව දර්ශනය කරන්න භාවිතා කරන්න පුලුවන්.

කලින් PHP කේතයේ 11,12,13 පේළි වලින් PHP වල SimpleXML parser එක භාවිතා කරලා මේ දත්ත දෙක එළියට අරගෙන පිලිවෙලින් $id සහ $display_name යන variable දෙකට පිටපත් කරලා තිබෙනවා. දැන් අවශ්‍ය නම් මෙම අගයන් දෙක session එකේ තැන්පත් කරන්න පුලුවන් පහත ආකාරයට.

$_SESSION['id'] = $id;
$_SESSION['name'] = $display_name;
$_SESSION['logged_in'] = true;

Logout වීමේදී මෙම $_SESSION[] variable clear කර දැමිය හැකියි.

ඉහත පලමුවැනි PHP පිටුව save කර PHP සර්වරයක් වෙත upload කරන්න (වෙබ් සර්වරය curl සඳහා සහය දැක්විය යුතුය).

දැන් අපි නැවත අපේ වෙබ් අඩවිය වෙත හැරෙමු. පහත ‍HTML කේතය ඔබේ අඩවියේ login පිටුවේ යටින් (</html> ටැගයට පෙර) පිටපත් කරන්න.

<script src="https://rpxnow.com/openid/v2/widget" type="text/javascript"></script>
<script type="text/javascript">
RPXNOW.overlay = true;
RPXNOW.language_preference = 'en';
</script>

ඉන්පසුව Login වීමට click කල යුතු ‍තැනට වෙනුවට මෙම කේතය පිටපත් කරන්න.

<a class="rpxnow" onclick="return false;" href="https://test-application2.rpxnow.com/openid/v2/signin?token_url=your_token_url">
Sign In
</a>

මෙහිදී token_url ඉදිරිපිට your_token_url වෙනුවට ඔබ වෙබ් සර්වරයට upload කල ගොනුවේ ලිපිනය ලබා දෙන්න. අවශ්‍යනම් Sign In පදය වෙනුවට පින්තූරයක් හෝ වෙනත් පදයක් ලබා දෙන්න පුලුවන්.

දැන් ඔබගේ අඩවියට OpenID හා ඔබ RPXnow තුල ලබා දුන් සේවාදායකයින්ගේ ගිණුම් භාවිතා කර පරිශීලකයින්ට ඇතුලු වෙන්න පුලුවන්. අවශ්‍යනම් පසුව භාවිතා කිරීමට පරිශීලකයින් අනන්‍ය වශයෙන් හඳුනා ගැනීමේ දත්ත ලබා දෙන අතරම අනවශ්‍ය මොඩුයලයක් ඔබේ අඩවියෙන් ඉවත් කර ගන්නත් OpenID පහසුකම යොදා ගන්න පුලුවන්.

පහළ පින්තූරයේ තිබෙන්නේ මෙම ක්‍රියාවලිය සරල ලෙස දක්වලා. තේරුම් ගන්න පහසු වෙයි කියලා හිතුන නිසා මේක හැදුවේ

]]> http://www.techbuzz.chamiladealwis.com/2010/01/relying-on-openid-janrain-rpx/feed/ 7 http://www.techbuzz.chamiladealwis.com/2010/01/openid-service-providers/ http://www.techbuzz.chamiladealwis.com/2010/01/openid-service-providers/#comments Sun, 24 Jan 2010 06:35:32 +0000 පිටස්තරයා http://www.techbuzz.chamiladealwis.com/?p=189 අවසාන ලිපියේ සඳහන් වුන විදියට අපිට OpenID සේවාව ලබා ගත හැකි ක්‍රම දෙකක් තියෙනවා.

1. දැනටම මෙම සේවාව ලබා දෙන තැනකින් අපට URL එකක් ලබා ගැනීම
2. අපගේ domain එකක් භාවිතා ‍කර එය OpenID එකක් ලෙස යොදා ගැනීම

දැනටමත් OpenID සේවාව ලබා දෙන ප්‍රසිද්ධ සේවාදායකයින් කිහිප දෙනෙක් සිටිනවා. මෙතනදී සේවා දායකයෙක් කියන්නේ OpenID සම්මුතියට එකඟව සේවාව සපයන අය. OpenID ප්‍රධාන වශයෙන් අනන්‍ය වෙන්නේ මෙවැනි සේවාදායකයින් විසිරී තිබිම නිසා. ඒ කියන්නේ ඒක විමධ්‍යගත (decentralized) ක්‍රමවේදයක්. මූලිකවම OpenID කියන්නේ සම්මතයක් පමණයි.

මෙවැනි ප්‍රසිද්ධ සේවාදායකයින් කිහිප දෙනෙක් සිටිනවා. මෙම සේවාදායකයින් ළඟ ලියාපදිංචි වුනාට පස්සේ අපිට ලැබෙන්නේ URL එකක්. අපි OpenID භාවිතා කර පිවිසීමට හැකියාව ඇති අඩවි තුලට පිවිසෙන්නේ මෙම URL එක භාවිතා කරලා. මෙම ක්‍රියාවලිය ගැන මීලඟ ලිපියෙන් වැඩිදුර විස්තර කරන්න බලාපොරොත්තු වෙනවා. පහත තිබෙන්නේ OpenID සේවාදායකයින් කිහිප දෙනෙක් පිළිබඳ තොරතුරු.

1. Google Accounts
   • බහුතරයකට දැනටමත් තියෙන දෙයක් තමයි Gmail ගිණුම්. බහුතරයක් නොදැනගෙන හිටපු දෙයක් තමයි මේ ගිණුම අපිට වෙනත් සේවා භාවිතා කරන්නත් යොදාගන්න පුලුවන් කියන එක. උදාහරණයකට අපි Blogger බ්ලොග් එකකට ප්‍රතිචාරයක් යොදන කොට අපිව හඳුනා ගැනීම සඳහා Gmail ගිණුම යොදා ගන්න පුලුවන්. මේ ස‍ඳහා Login වීමට ඇති තැන Google ලාංඡනය ඇති දැයි සොයා බලන්න. එය මත click කල පසු ඔබව Google Accounts Login පිටුවට රැගෙන යයි (මෙය http://google.com/accounts විය යුතුයි. අවම වශයෙන් google ඩොමේනය විය යුතුයි. වෙනත් ඩොමේනයක්නම් ඔබගේ රහස්‍ය තොරතුරු ඇතුලත් කරන්න එපා. බොහෝ විට OpenID authentication සිදු වෙන්නේ අදාල සේවාදායකයාගේ ඩොමේනයේ සිට මිස අප ඇතුලත් වීමට දරණ අඩවියේ නොවෙයි.).  එහිදී ඔබගේ Google ගිණුමට ඇතුලු වූ පසු ඔබව නැවත අදාල අඩවියට යොමු කරයි.
2. Yahoo Accounts
   • Google ගිණුම භාවිතා කල ආකාරයෙන්ම Yahoo ගිණුමද භාවිතා කල හැකියි. අදාල අඩවියේ Yahoo ලාංඡනයක් තිබෙනවානම් එය මත click කරන්න.
3. Blogger
   • ඔබට Blogger බ්ලොග් එකක් තිබෙනවානම් (http://xxxxx.blogspot.com) (Google ගිණුමක් තිබෙනවානම් Blogger ගිණුමක් ති‍බෙනවා. එය සක්‍රීය කර ගැනීම පමණයි අවශ්‍ය. ඒ සඳහා http://blogger.com වෙත යොමු වෙන්න.) එහි URL එක ඔබේ OpenID URL ලෙස භාවිතා කල හැකියි. එවිට ඔබව Blogger පිටුවට යොමු‍වෙනවා.  මේ විදියට Blogger OpenID ලෙස භාවිතා කර ඇති ලින්ක් එකක් මත click කලොත් අදාල බ්ලොග් පිටුවට යොමුවෙනවා.
4. Wordpress.com
   • Wordpress.com බ්ලොග් එකක් (http://xxxx.wordpress.com) භාවිතා කරනවානම් ඔබට එහි URL එකත් OpenID URL එක ලෙස භාවිතා කරන්න පුලුවන්. මෙය භාවිතා කර ඇති තැන් වලිනුත් යොමු වෙන්නේ අදාල Wordpress.com බ්ලොග් අඩවියට.
5. ClaimId.com
   • මෙය OpenID සේවාදායකයෙක් ලෙසම ඇති සේවයක්. http://claimid.com වෙත ගොස් ඔබට claimid.com ගිණුමක් ලබා ගන්න පුලුවන්. එවිට එබට ලැබෙන්නේ URL එකක්. එය සාමාන්‍යයෙන් http://claimid.com/my_username ආකාරයෙන් පවතින්නේ.
   • Claimid භාවිතා කල තැනක් යොමු‍ වෙන්නෙ අප claimid තුල සාදන පිටුවක් වෙතට. නමුත් අපට අවශ්‍යනම් අපගේ පිටුවකට එය යොමු වෙන ආකාරයට සාදා ගත හැකියි. මෙය OpenID තුල හැඳින්වෙන්නේ delegation යනුවෙන්.
6. chi.mp
   • මෙය ටිකක් වෙනස් ආකාරයේ සේවාදායකයෙක්. http://chi.mp වෙත ගොස් අපට අපගේම .mp ඩොමේනයක් සාදා ගන්න පුලුවන්. ඉන් පසු එම ඩොමේනය අපගේ OpenID URL එක ලෙස භාවිතා කරන්න පුලුවන්. උදාහරණයකට මට http://chamila.mp යන ඩොමේනය භාවිතා කරමින් OpenID පහසුකම ඇති අඩවියකට පිවිසෙන්න පුලුවන්.
   • chi.mp වල විශේෂත්වය වෙන්නේ OpenID සේවාදායකයෙකු වෙමින් වෙනත් සේවා ලබා ගැනීමටත් හැකියාව තිබීම. අපගේ twitter, facebook වැනි ගිණුම් මධ්‍යගතව හසුරවන්න පුලුවන් සේවා chi.mp මගින් ලබා දෙනවා. එහිදී අනවශ්‍ය ලෙස අපගේ රහස් පද ඉල්ලා සිටින්නේ නෑ. මෙයට අමතරව chi.mp වෙතින් අපට ඔවුන් සාදාදෙන අඩවියකුත් ලබා දෙනවා. එය පෞද්ගලික වෙබ් අඩවියක් ලෙසත් භාවිතා කිරීමට පුලුවන්.

මේ ලැයිස්තුව දිහා බැලුවොත් පේනවා දැනටමත් ඔබට OpenId ගිණුමක් තිබීමේ වැදගත් සම්භාවිතාවක් තියෙනවා කියලා. OpenId වල තියෙන අලංකාරය මේකයි. එය මධ්‍යගතව නැහැ. එයට භාරකාරයො නැහැ. OpenId.net, OpenId සම්මුතිය නඩත්තු කිරීමට ඇති සංවිධානයක් පමණයි.

ඔබට හෝ ඔබගේ සමාගමට අවශ්‍ය නම් කිසිම වියදමක් දරන්නේ නැතුව OpenID සේවාදායකයෙකු විය හැකියි. ඒ සඳහා අවශ්‍ය තාක්ෂණික දැනුම හිඟ නම් delegation යොදා ගෙන වෙනත් සේවාදායකයින් හරහා authentication කාර්යය කරවා ගන්න පුලුවන්.

සයිබර් සංස්කෘතිය ඇතුලේ අනන්‍යතාවය ඉතාමත් වැදගත්. මොකද අපි ලියන කියන දේවල් මොන ආකාරයෙන් කොහේ පිටපත් වෙලා කවුරු අපිව අනුකරණය කරනවාද කියන එක හරියටම කියන්න බැහැ. එම නිසා හැකි සෑම අවස්ථාවකම අනන්‍යතාවයකින් පෙනී සිටින්න පුලුවන් නම් වඩාත් හොඳයි. මේ සඳහා අවශ්‍ය තාක්ෂණික පහසුකම OpenID වෙති සාර්ථකව ලබා දීලා තියෙනවා.

මීළඟ ලිපියෙන් OpenID පහසු කම අඩවියකින් ලබා දෙන හැටි විස්තර කර ගනිමු.

ඊට පස්සේ ඉතාමත් දක්ෂ අදහසක් මතු වුනා. මේ සියළු වෙනස් සේවා පරිශීලනය කරන්න එකම එක authentication එකක් තිබුනොත් කොහොමද? ඒ කියන්නේ blogger වලට ඇතුලු වෙන්නත් yahoo වලට ඇතුලු වෙන්නත් වෙනත් ප්‍රසිද්ධ නැති සේවාදායකයෙකුගේ සේවයකට ඇතුලු වෙන්නත් එක username/password ද්විත්වයක් තිබුනොත් සහ ඒ සියළු දේට ඇතුලු වෙන්න එක පාරක් විතරක් authenticate කර ගෙන පුලුවන් වුනොත් කොහොමද?

මේ විදියට තමයි single sign-on කියන සංකල්පය අන්තර්ජාලයට ඇතුලු වෙන්නේ. මෙතනදි එක මධ්‍යගත සේවාදායකයෙක් ඉන්නවා. ඔහු තමයි authentication කර්තව්‍යය සිදු කරන්නේ. පහළ තියෙන්නේ මේ සිදුවීම් ජාලාවේ අවුල් ලිහලා ගත්ත version එකක්.

1. මුලින්ම ඒ මධ්‍යගත සේවාදායකයා (A) ලඟ අපි ලියාපදිංචි වෙන්න ඕනේ. එතකොට එතනින් අපිට URL එකක් දෙනවා අපිව අඳුන ගන්න.
2. අපිට සේවය අවශ්‍ය කරන සේවාදායකයගේ (B) වෙබ් අඩවියට ගියාට පස්සේ එතනින් අපිට අපේ URL ඇතුල් කරන්න තැනක් ලබා දෙනවා (තාම password එකක් ඇතුලු කලේ නෑ).
3. දැන් B විසින් අපිව අර මධ්‍යගත සේවාදායකයගේ වෙබ් පිටුවට (A) redirect කරනවා. එවිට අපි එතන username එක සහ password එක ලබා දී authenticate කර ගන්න ඕනේ.
4. දැන් A විසින් අපෙන් අහනවා B වෙතට අපේ තොරතුරු (credentials) යවන්න ද කියලා. අපිට අවශ්‍යනම් අපි අනුමැතිය ලබා දෙනවා. එතකොට කරුණු දෙකක් වෙනවා.
   1. B වෙතට අපේ තොරතුරු (credentials) යැවෙනවා
   2. අපේ browser එකට token එකක් ලැබෙනවා (cookie එකක් ලෙසට). මෙය තමයි අපි එම cookie/token එකට අදාල කාලය සඳහා A වෙතින් authenticate කර ගත් බවට ලැබෙන සහතිකය
5. දැන් B වෙතට ලැබෙන විස්තර වලින් B අපිව authenticate කර ගන්නවා. එතැනට අවශ්‍යනම් (A වෙතින් ලැබෙන) අපගේ identifier එකක් ගබඩා කර තබා ගත හැකියි. පරිශීලක ‍දත්ත වෙනුවට B හට A වෙතින් ලැබෙන තොරතුරු (credentials) භාවිතා කල හැකියි.
6. දැන් අපි තවත් single sign-on enable කර ඇති සේවා දායකයෙකුගේ (C) වෙබ් අඩවියකට පැමිණියහොත් A වෙතට නොගොස් අපට කලින් A වෙතින් ලැබුණු token එක ඉදිරිපත් කල හැකියි. එය expire වී නැතිනම් අපව C විසින් authenticate කර ගන්නවා. එවිට C හටත් එම token එක භාවිතා කර අ‍පගේ විස්තර ලබා ගත හැකියි.
7. අදාල token එක expire වූ පසු නැවත භාවිතා කිරීමට අවශ්‍යනම් අපි නැවත A වෙත ගොස් authenticate කර ගත යුතුයි.

පැහැදිලි මදි වගේද? අපි උදාහරණයකට යමු OpenID ගැන කතා කලාට පසුව.

මෙම single sign-on ක්‍රමය ක්‍රියාත්මක කරන්න මුලින්ම කර ගැහුවේ Microsoft .net Certificate යනුවෙන්. එය ටික ‍කාලෙකට පස්සේ නොයෙකුත් හේතු උඩ අසාර්ථක වුනා. මම දන්න ආකාරයට Kerberos යනුවෙන් තිබුණු පද්ධතියත් එවැනි කාර්යයක් සිදු කලා. නමුත් එයත් වඩාත් ජනප්‍රිය වුනේ නෑ.

OpenID මෙම කරළියට එන අලුත්ම මෙන්ම වැඩියෙන්ම ජනප්‍රිය වෙච්ච implementation එක. එය implementation එකකටත් වඩා සම්මතයක් කීවොත් නිවැරදියි. අපි කලින් flow එකේදි එක් මධ්‍යගත ස්වාදායකයෙකු (A) ගැන කතා කලා. OpenID වලදි මේක ටිකක් වෙනස් වෙනවා. එහි මධ්‍යගත (centralized) වෙනුවට විමධ්‍යගත (decentralized) සේවාදායකයින් කිහිප දෙනෙක් සිටිනවා. අපට වුනත් අලුත් OpenID සේවාදායකයෙකු ලෙස එකතු විය හැකියි. ඉතුරු කාර්යයන් ටික බොහෝ දුරට සමානයි. OpenID වල වැඩි පුර වාසියක් වෙන්නේ එය එක් authentication ආකාරයක් බල කරන්නේ නැති බව. ඒ නිසා අපට username/password වෙනුවට ඇඟිළි සළකුණු, SmartCards වැනි දේත් authentication සඳහා යොදා ගන්න පුලුවන්. ඉතාමත් ගුණාත්මක ආකාරයේ authentication ආකාරයක් භාවිතා කරමින් OpenID වඩා ආරක්ෂාව වැදගත් කටයුතු (උදා: බැංකු කටයුතු) වලටත් යොදා ගන්න පුලුවන්.

අපට OpenID එකක් ලබා ගත හැකි ක්‍රම දෙකක් තිබෙනවා.

• දැනටම මෙම සේවාව ලබා දෙන තැනකින් අපට URL එකක් ලබා ගැනීම
• අපගේ domain එකක් භාවිතා ‍කර එය OpenID එකක් ලෙස යොදා ගැනීම

දැනට OpenID සේවාව ලබා ගත හැකි බොහෝ ස්ථාන තිබෙනවා. ClaimID, MyOpenID වැනි සේවාදායකයින්ගෙන් අපට OpenID එකක් ලබා ගත හැකියි. ඒ වගේම Google, Yahoo, Blogger, Wordpress වැනි සංවිධාන වලින් ඔවුන්ගේ පරිශීලකයින්ට OpenID සේවාව ලබා දෙනවා. ඔබට දැනටමත් මෙම සේවාදායකයින්ගේ ගිණුමක් තිබෙනවනම් එම අදාල URL (උදා: blogger වල නම් blogspot අඩවි ලිපිනය) එක OpenID එකක් ලෙස භාවිතා කල හැකියි. මෙම සේවාදායකයින් පිළිබඳ වැඩි විස්තර සඳහා http://openid.net/get-an-openid/ වෙතට යන්න.

OpenID පිළිබඳ වැඩි දුරටත් මීළඟ ලිපියෙන් බලාපොරොත්තු වෙන්න.

Bibliography

1. http://en.wikipedia.org/wiki/OpenID
2. http://openid.net/get-an-openid/

. වලින් පටන් ගන්න ගොනු ලිනක්ස් තුලදී නම් සැඟවුණු ගොනු (hidden files) ලෙසටයි ගන්නේ. එම නිසා ලිනක්ස් තුලදී එවැනි ගොනුවක් සෑදීම පහසුයි. නමුත් වින්ඩෝස් තුල එවැන්නක් නැහැ. ගොනුවක් සඟවන්න එහි attribute එකක් වෙනස් කරන්න ඕනේ (Dos තුලදී attrib +h <file_name> වැනි විධානයක්). ඒ වගේම වින්ඩෝස් තුල ලිනක්ස් වල නැති ගොනු වලට අදාල ගුණාංගයක් තියෙනවා. ඒක තමයි extension එක. මේක ලිනක්ස් වලදී අත්‍යවශ්‍ය නැහැ. නමුත් වින්ඩෝස් තුලදී extension එකක් ගොනුවක් හඳුනා ගැනීම හා ඒවා කියවීමට අත්‍යවශ්‍යයි. Extension එකක් නැති වුවහොත් එය බලෙන් කියවීමට අපට සිදුවෙනවා. සාමාන්‍යයෙන් වින්ඩෝස් තුල ගොනු නාමය (file name) හා extension එක වෙන වෙන්නේ තිතකින් (උදා: usp10.dll).

වින්ඩෝස් ඇතුලෙදි .htaccess ගොනුවක් සාදන්න සාමාන්‍යයෙන් බැහැ. මොකද ඒකට file name එකක් නැති නිසා. extension එකක් පමණක් ඇති ගොනු තිබෙන්න බැහැ. මේ කරදරය වලක්වා ගැනීම සඳහා අපට Notepad යොදා ගන්න පුලුවන්.

අපට .htaccess ගොනුවට දැමීමට අවශ්‍ය ‍දේ Notepad විවෘත කර ඒ තුල ලියන්න. ඉන්පසුව Save වෙත ගොස් එහි File name තුල “.htaccess” ලෙස (double quotation ද ඇතුලුව) යොදන්න. දැන් අදාල ගොනුව සෑදි තිබෙන හැටි දකින්න පුලුවන්. මෙය ඔබට අදාල තැනට පිටපත් කර ගන්න.

ලිනක්ස් තුලට eclipse ස්ථාපනය කර ගන්න පුලුවන් විධි දෙකක් (සාමාන්‍යයෙන්) තියෙනවා. එකක් package manager භාවිතා කරලා ස්ථාපනය කර ගන්න එක. මේ ක්‍රමයෙන් ස්ථාපනය වෙන eclipse ටිකක් පරණ වෙන්න පුලුවන්. අනිත් එක eclipse අඩවියට ගිහින් තියෙන අලුත්ම එක බාගත කරගෙන අතින් ස්ථාපනය කරන එක. අපි මේ ක්‍රමය අනුගමනය කරමු.

මුලින්ම තමන්ට අවශ්‍ය eclipse අනුවාදය බාගත කර ගන්න. ඒක හුඟක් වෙලාවට ~/Downloads ඇතුලට ටාර්බෝල් එකක් විදියට තමයි බාගත වෙන්නේ. දැපහත විධාන ටික ටර්මිනලයක ඇතුලත් කරන්න. මුලින්ම අපි root වෙලා හිටියොත් හරි නැත්තන් sudo තියෙනවනම් ඒක භාවිතා කලොත් හරි හොඳයි. මම sudo විදියට කරන්නම්.

sudo mv ~/Downloads/eclipse-java-*****.tar.gz /usr/local/
cd /usr/local
sudo tar -xzf eclipse-java*****.tar.gz
sudo chown -R your_username:your_group_name eclipse
sudo ln -s /usr/local/eclipse/eclipse /usr/local/bin/eclipse

පළවෙනි පේළියෙන් කරන්නේ දැනට බාගත කරපු .tar.gz ගොනුව /usr/local ඩිරෙක්ටරිය ඇතුලට move කරන එක. සාමාන්‍යයෙන් ලිනක්ස් ඇතුලේ මෘදුකාංග ස්ථාපනය කරන්නේ /usr හෝ /usr/local ඇතුලේ. දෙවෙනි පේළියෙන් අපි ඒ ඩිරෙක්ටරිය ඇතුලට යනවා.

තුන්වෙනි පේළියෙන් කරන්නේ .tar.gz ගොනුව extract කරන එක.  ඊට පස්සේ ls -l කියලා විධානය දුන්නොත් ඔබ දකියි /usr/local/eclipse යනුවෙන් ඩිරෙක්ටරියක් හැදිලා තියෙන බව. නමුත් තාමත් ඒ ගොනුව අයිති අපිට නෙමෙයි. ඒක අපේ අතට ගන්න එක තමයි හතරවෙනි පේළියෙන් කරන්නේ. මෙතනදි your_username වෙනුවට ඔබ භාවිතා කරන පරිශීලක නම දෙන්න. your_group_name වෙනුවට ඔබේ සමූහයේ නම දෙන්න. ඒක හුඟක් වෙලාවට ඔබේ පරිශීලක නමම තමයි. මම දුන්නේ chamila:chamila  කියලා. chown විධානයෙන් කරන්නේ අදාල ගොනුවේ (හෝ ඩිරෙක්ටරියෙ. ලිනක්ස් තුල හැම එකක්ම ගොනුවක්!) අයිතිකාරයා වෙනස් කරන එක.

දැන් අන්තිමට කරන්නේ තියෙන්නේ ටර්මිනලයේ eclipse කියලා විධානය දුන්නාම eclipse විවෘත වෙන විදියට පොඩි සබැඳියක් දාන එක. මේකට අපි හදනවා symbolic link එකක්. මේකත් ගොනු වර්ගයක්. නමුත් symbolic link එකකින් කරන්නේ වෙනත් ගොනුවකට යොමු කිරීම. හරියට වින්ඩෝස් වල shortcut (.lnk ගොනුවක්) එකක් වගේ. මේ සඳහා අපි පස්වෙනි පේළියේ විධානය දෙනවා. එතනින් කරන්නේ /usr/local/eclipse/eclipse ගොනුවට shortcut එකක් /usr/local/bin/ ඩිරෙක්ටරිය තුල යෙදීමයි.

දැන් ටර්මිනලය තුල eclipse යනුවෙන් විධානය ලබා දී බලන්න. අවශ්‍යනම් Gnome පැනලයකට launcher එකක් ඇතුලත් කල හැකියි. එහි command තුලට eclipse යනුවෙන් ලබා දීම පමණයි අවශ්‍ය.