تسجيل الدخول التلقائي إلى مؤتمرات Lync على Linux

يا هبر!

بالنسبة لي، هذه العبارة أقرب إلى مرحباً بالعالم، منذ أن وصلت أخيرًا إلى منشوري الأول. لقد قمت بتأجيل هذه اللحظة الرائعة لفترة طويلة، لأنه لم يكن هناك ما أكتب عنه، ولم أرغب أيضًا في امتصاص شيء تم امتصاصه بالفعل عدة مرات. بشكل عام، في منشوري الأول، أردت شيئًا أصليًا ومفيدًا للآخرين ويحتوي على نوع من التحدي وحل المشكلات. والآن يمكنني مشاركة هذا. الآن دعونا نتحدث عن كل شيء بالترتيب.

دخول

بدأ كل شيء عندما قمت منذ بعض الوقت بتنزيل Linux Mint على جهاز الكمبيوتر الخاص بي. ربما يعرف الكثير من الناس أن Pidgin المزود بملحق Sipe هو بديل مناسب تمامًا لبرنامج Microsoft Lync (المعروف الآن باسم Skype for Business) لأنظمة Linux. نظرًا لتفاصيل عملي، غالبًا ما أضطر إلى المشاركة في مؤتمرات SIP، وعندما كنت عاملاً في Windows، كان الدخول إلى المؤتمرات أمرًا أساسيًا: نتلقى دعوة عبر البريد، وننقر على رابط تسجيل الدخول، ونحن على استعداد للذهاب .

عند التحول إلى الجانب المظلم من Linux، أصبح كل شيء أكثر تعقيدًا إلى حد ما: بالطبع، يمكنك أيضًا تسجيل الدخول إلى المؤتمرات في Pidgin، ولكن للقيام بذلك تحتاج إلى تحديد خيار الانضمام إلى المؤتمر في القائمة في خصائص حساب SIP الخاص بك و في النافذة التي تفتح، أدخل رابطًا للمؤتمر أو أدخل اسم المنظم ومعرف الثقة. وبعد مرور بعض الوقت بدأت أفكر: "هل من الممكن تبسيط هذا بطريقة أو بأخرى؟" "نعم، قد تقول، لماذا بحق الجحيم تحتاج إلى هذا؟ أفضل الجلوس على نظام التشغيل Windows وعدم ذهلي.

الخطوة 1: البحث

قال نيكراسوف في عمله "من يعيش بشكل جيد في روس" "إذا خطرت في ذهنك بعض النزوات، فلا يمكنك التخلص منها بالوتد".

لذلك، بمجرد أن دخلت الفكرة في رأسي، بعد مرور بعض الوقت، نشأت الفكرة الأولى للتنفيذ. بدا كل شيء بسيطًا - تحتاج إلى اعتراض الوصول إلى الروابط meet.company.com/user/confid - قم بتثبيت عملية تطبيق ويب محلي على سيارتك على 127.0.0.1 وفي /etc/hosts أضف إدخالاً ثابتًا لمجال الشركة الذي تدخل من خلاله إلى المؤتمر، مشيرًا إلى المضيف المحلي. بعد ذلك، يجب على خادم الويب هذا معالجة الرابط الذي وصل إليه ونقله بطريقة ما داخل Pidgin (سأقول على الفور أنه في هذه المرحلة ما زلت لا أملك أي فكرة عن كيفية إعطائه له على الإطلاق). الحل بالطبع يشبه رائحة العكازات، لكننا مبرمجون، العكازات لا تخيفنا (تبا).

وبعد ذلك، وبمحض الصدفة، قمت بطريقة ما بفتح رابط الدعوة في Google Chrome (وعادةً ما أستخدم Mozilla Firefox دائمًا). ولدهشتي، بدت صفحة الويب مختلفة تمامًا - لم يكن هناك نموذج لإدخال بيانات المستخدم وبعد الدخول إلى الصفحة مباشرة كان هناك طلب لفتح شيء ما من خلاله XDG فتح. للمتعة فقط، أنقر فوق "نعم" وتظهر رسالة خطأ - لا يمكن فتح الرابط lync15:confjoin?url=https://meet.company.com/user/confid. همم. ما هو نوع xdg-open وما الذي يحتاجه لفتح هذه الروابط؟ كشفت قراءة ما بعد الوفاة للوثائق أنه معالج واجهة المستخدم الرسومية الذي يساعد في تشغيل التطبيقات المرتبطة إما باستخدام بروتوكولات نظام uri أو مع أنواع ملفات محددة. يتم تكوين الارتباطات عبر تعيين نوع mime. لذلك نرى أننا نجري بحثًا عن تطبيق مطابق لمخطط uri اسمه lync15 ويتم تمرير الرابط إلى xdg-open، والذي، من الناحية النظرية، يجب أن يمرره إلى بعض التطبيقات المسؤولة عن هذا النوع من الارتباط. وهو ما لا نملكه في نظامنا بالطبع. إذا لم يكن الأمر كذلك، فماذا يفعلون في عالم مفتوح المصدر؟ هذا صحيح، سنكتبه بأنفسنا.

مزيد من الانغماس في عالم Linux وخاصة في دراسة كيفية عمل الغلاف الرسومي (بيئة سطح المكتب، DE)، بالمناسبة، لدي Xfce في Linux Mint، أظهر أن التطبيقات ونوع mime المرتبط بها عادةً ما تتم كتابتهما مباشرة بلغة الملفات المختصرة ذات الامتداد .desktop. حسنًا، لماذا لا، أقوم بإنشاء اختصار تطبيق بسيط، والذي يجب ببساطة تشغيل برنامج نصي bash وإخراج الوسيطة التي تم تمريرها إليه إلى وحدة التحكم، وأقدم ملف الاختصار نفسه فقط:

[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;

أقوم بتشغيل xdg-open من وحدة التحكم، وأمرر نفس الرابط الذي يأتي من المتصفح و... المشكلة. مرة أخرى تقول أنه لا يمكن معالجة الارتباط.

كما اتضح، لم أقم بتحديث دليل أنواع mime المرتبطة بالتطبيق الخاص بي. ويتم ذلك بأمر بسيط:

xdg-mime default lync.desktop x-scheme-handler/lync15

الذي يقوم ببساطة بتحرير الملف ~/.config/mimeapps.list.

المحاولة رقم 2 باستخدام استدعاء xdg-open - وفشلت مرة أخرى. لا شيء، الصعوبات لا تخيفنا، بل تغذي اهتمامنا فقط. وباستخدام كل قوة bash (أي التتبع)، فإننا نتعمق في تصحيح الأخطاء. من المهم أن نلاحظ هنا أن xdg-open هو مجرد برنامج نصي لـ Shell.

bash -x xdg-open $url

تحليل المخرجات بعد التتبع يصبح من الواضح قليلاً أن التحكم يتم نقله بعد ذلك مفتوح خارجيًا. وهذا بالفعل ملف ثنائي ومن الصعب فهم سبب قيامه بإرجاع رمز إرجاع غير ناجح عند تمرير رابط إليه في الوسيطة.

بعد أن بحثت في الأجزاء الداخلية لـ xdg-open، اكتشفت أنه يحلل المعلمات البيئية المختلفة ويمرر التحكم إما إلى بعض الأدوات لفتح روابط الملفات الخاصة بـ DE معين، أو أن لديه وظيفة احتياطية open_generic

open_xfce()
{
if exo-open --help 2>/dev/null 1>&2; then
exo-open "$1"
elif gio help open 2>/dev/null 1>&2; then
gio open "$1"
elif gvfs-open --help 2>/dev/null 1>&2; then
gvfs-open "$1"
else
open_generic "$1"
fi

if [ $? -eq 0 ]; then
exit_success
else
exit_failure_operation_failed
fi
}

سأقوم سريعًا بتضمين اختراق صغير هنا مع تحليل الوسيطة التي تم تمريرها وما إذا كانت سلسلتنا الفرعية المحددة موجودة هناك لينك15:، ثم ننقل التحكم على الفور إلى الوظيفة open_generic.

المحاولة رقم 3 وهل تعتقد أنها نجحت؟ نعم الآن بالطبع. لكن رسالة الخطأ قد تغيرت بالفعل، وهذا بالفعل تقدم - الآن كان يخبرني أنه لم يتم العثور على الملف وفي شكل ملف كتب لي نفس الرابط الذي تم تمريره كوسيطة.

هذه المرة تبين أنها وظيفة is_file_url_or_path، الذي يقوم بتحليل رابط الملف الذي تم تمريره إلى الإدخال: file:// أو المسار إلى الملف أو أي شيء آخر. ولم يعمل التحقق بشكل صحيح لأن البادئة (مخطط عنوان url) لدينا تحتوي على أرقام، والتعبير العادي يتحقق فقط من مجموعة الأحرف التي تتكون من:alpha: النقاط والشرطات. بعد استشارة معيار rfc3986 لـ معرف الموارد الموحد أصبح من الواضح أن Microsoft هذه المرة لا تنتهك أي شيء (على الرغم من أن لدي مثل هذا الإصدار). فقط فئة الأحرف :alpha: تحتوي فقط على أحرف الأبجدية اللاتينية. أقوم بسرعة بتغيير الشيك العادي إلى أبجدي رقمي. تم، أنت رائع، كل شيء بدأ أخيرًا، التحكم بعد إجراء جميع عمليات التحقق لتطبيق البرنامج النصي الخاص بنا، يتم عرض الرابط الخاص بنا على وحدة التحكم، كل شيء كما ينبغي أن يكون. بعد ذلك، بدأت أشك في أن جميع مشكلات exo-open ترجع أيضًا إلى التحقق من صحة تنسيق الارتباط بسبب الأرقام الموجودة في المخطط. لاختبار الفرضية، قمت بتغيير تسجيل التطبيق من نوع mime إلى مجرد مخطط الوشق وفويلا - كل شيء يعمل دون تجاوز وظيفة open_xfce. ولكن هذا لن يساعدنا بأي شكل من الأشكال، لأن صفحة الويب الخاصة بالدخول إلى المؤتمر تقوم بإنشاء رابط مع lync15.

وبذلك يكون الجزء الأول من الرحلة قد اكتمل. نحن نعرف كيفية اعتراض اتصال الارتباط ثم يجب معالجته بطريقة ما وتمريره داخل Pidgin. من أجل فهم كيفية عمله داخليًا عند إدخال البيانات عبر رابط في قائمة "الانضمام إلى مؤتمر"، قمت باستنساخ مستودع Git الخاص بمشروع Sipe واستعدت للتعمق في الكود مرة أخرى. ولكن بعد ذلك، لحسن الحظ، انجذبت إلى النصوص الموجودة في الكتالوج مساهمة / دبوس /:

  • sipe-الانضمام إلى المؤتمر-with-uri.pl
  • sipe-join-conference-with-organizer-and-id.pl
  • sipe-call-phone-number.pl
  • SipeHelper.pm

اتضح أن ملحق Sipe متاح للتفاعل عبر dbus (desktop bus) ويوجد داخل البرامج النصية أمثلة للانضمام إلى مؤتمر عبر رابط، إما من خلال اسم المنظم ومعرف conf، أو يمكنك بدء مكالمة عبر sip . هذا هو بالضبط ما كنا في عداد المفقودين.

الخطوة 2. تنفيذ معالج الانضمام التلقائي

نظرًا لوجود أمثلة جاهزة في Pearl، فقد قررت استخدامها فقط sipe-الانضمام إلى المؤتمر-with-uri.pl وقم بتعديله قليلاً بما يناسبك. يمكنني الكتابة باللغة اللؤلؤية، لذلك لم يسبب ذلك أي صعوبات خاصة.

بعد اختبار البرنامج النصي بشكل منفصل، كتبت استدعائه في الملف lync.desktop. وكان النصر! عند الدخول إلى صفحة الانضمام إلى المؤتمر والسماح بتشغيل xdg-open، سيتم فتح نافذة المؤتمر المنبثقة من Pidgin تلقائيًا. كم فرحت.
وبعد أن شجعني النجاح، قررت أن أفعل الشيء نفسه بالنسبة لمتصفحي الرئيسي، Mozilla Firefox. عند تسجيل الدخول عبر الثعلب، تفتح صفحة الترخيص وفي الأسفل يوجد زر الانضمام باستخدام مكتب التواصل. كانت هي التي لفتت انتباهي. وعندما تضغط عليه في المتصفح يذهب إلى العنوان:

conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio

والذي أخبرني بلطف أنه لا يعرف كيفية فتحه، وربما ليس لدي تطبيق مرتبط بهذا البروتوكول. حسنًا، لقد مررنا بهذا بالفعل.

أقوم بسرعة بتسجيل تطبيق البرنامج النصي الخاص بي أيضًا لنظام uri أسيوط و... لا يحدث شيء. يستمر المتصفح في الشكوى من عدم وجود تطبيق يتعامل مع الروابط الخاصة بي. في هذه الحالة، يعمل استدعاء xdg-open من وحدة التحكم باستخدام المعلمات بشكل مثالي.

"تعيين معالج بروتوكول مخصص في فايرفوكس" - لقد اتصلت بالإنترنت بهذا السؤال. بعد إجراء العديد من المناقشات حول تدفق المكدس (وأين سنكون بدونه)، يبدو أنه تم العثور على الإجابة. تحتاج إلى إنشاء معلمة خاصة في حول: التكوين (بالطبع استبدال foo بـ conf):

network.protocol-handler.expose.foo = false

لقد قمنا بإنشائه وفتح الرابط و... لم يحالفنا الحظ. المتصفح، وكأن شيئا لم يحدث، يقول أنه لا يعرف طلبنا.

أنا أقرأ الوثائق الرسمية حول تسجيل البروتوكول من Mozilla، وهناك خيار لتسجيل الارتباطات في سطح مكتب جنوم نفسه (استبدال foo بـ conf بالطبع):

gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true

قمت بالتسجيل، افتح المتصفح... ومرة ​​أخرى اللحية.

هنا سطر من الوثائق يلفت انتباهي:

في المرة القادمة التي تنقر فيها على رابط من نوع بروتوكول foo، سيتم سؤالك عن التطبيق الذي تريد فتحه به.

- سيميون سيمينيتش
- اه

نحن لا ننقر على الرابط، ولكن صفحة الويب تقوم ببساطة بتغيير window.location عبر جافا سكريبت. أكتب ملف html بسيطًا به رابط لبروتوكول conf، وافتحه في المتصفح، وانقر على الرابط - Yos! تفتح نافذة تسألك عن التطبيق الذي نحتاج إلى فتح الرابط الخاص بنا، ويوجد لدينا بالفعل تطبيق Lync الخاص بنا في القائمة - لقد قمنا بتسجيله بأمانة بكل الطرق الممكنة. يوجد في النافذة مربع اختيار "تذكر الاختيار وافتح الروابط دائمًا في تطبيقنا"، ضع علامة عليه، وانقر فوق "موافق". وهذا هو النصر الثاني: تفتح نافذة المؤتمر. في الوقت نفسه، لا يعمل فتح المؤتمرات فقط عند النقر على الرابط، ولكن أيضًا عند الانتقال من صفحة الانضمام التي نحتاجها إلى المؤتمر.

ثم راجعت، وحذف المعلمات Network.protocol-handler.expose.conf لم يؤثر بأي شكل من الأشكال على عمل البروتوكول في فوكس. واستمرت الروابط في العمل.

اختتام

لقد قمت بتحميل جميع أعمالي إلى مستودع GitHub، وستكون الروابط لجميع الموارد في نهاية المقالة.
سأكون مهتمًا بتلقي التعليقات من أولئك الذين يرغبون في استخدام عملي. يجب أن أشير على الفور إلى أنني قمت بكل التطوير فقط لنظام Linux Mint الخاص بي، لذلك قد لا تعمل بعض التوزيعات أو أجهزة سطح المكتب الأخرى في هذا الإصدار. أو بالأحرى، أنا شبه متأكد من هذا، لأنني قمت بتصحيح وظيفة واحدة فقط في xdg-open والتي تتعلق فقط بـ DE الخاص بي. إذا كنت ترغب في إضافة دعم للأنظمة أو أجهزة سطح المكتب الأخرى، فاكتب لي طلبات السحب على Github.

استغرق المشروع بأكمله 1 مساء ليكتمل.

المراجع:

المصدر: www.habr.com

إضافة تعليق