Skype for SIP

Często na firmowych stronach internetowych są publikowane nazwy kont Skype. Być może potencjalni klienci używają Skype i może łatwiej (i za darmo) jest im zadzwonić przez Skype.

Jak to wygląda po stronie firmy? Ktoś musi mieć to konto Skype ustawione na swoim komputerze i odbierać przychodzące rozmowy. A co jak ta osoba ma urlop? Co jeśli jest akurat na przerwie obiadowej?

A jakby tak odbierać połączenia przychodzące Skype na normalnym telefonie biurkowym? Do tego właśnie Skype uruchomił usługę Skype for SIP. Trzeba mieć w centralce firmowej moduł telefonii internetowej obsługującej protokół SIP albo dokupić odpowiednią bramkę i podłączyć ją do centralki jako linię miejską. W ten sposób jeśli ktoś zadzwoni na konto Skype dzwonią telefony biurkowe tak jakby to było normalne połączenie z linii miejskiej. Więc może dzwonić na raz kilka telefonów i kto pierwszy odbierze ten rozmawia.

A co jeśli ktoś używa centralki telefonicznej VOIP ? Jeszcze prościej. Wystarczy, że ustawi sobie konto Skype for SIP jako kolejną linię miejską po protokole SIP.

Jakie są koszty?
4,95 euro netto za kanał czyli jakieś 20 zł miesięcznie.

Dodaj posta do:

Reminder: Up to and including March 15, 2010 it is free to create and allocate Business Accounts within your Business Control Panel. After this date Business Accounts will only be available as a premium paid-for feature of a Business Control Panel.

Czyli że tworzenie nowych kont w Skype dla firm będzie płatne. Czyli jak nasz pracownik odejdzie z firmy i zatrudnimy następnego to musimy zapłacić za utworzenie konta. Postanowiłem się dopytać w pomocy technicznej Skype ile to będzie kosztowało.  No bo jak mam w firmie wprowadzić jakieś rozwiązanie nie wiedząc ile w przyszłości będzie kosztowało? No i dostałem wielce satysfakcjonującą odpowiedź:

We apologise for the inconvenience.  We are working hard on making the
changes and notifying our business users as soon as possible.  However,
implementing changes and creating new features can take some time which
is why we just have sent notifications at this time.

Please be patient while we are working on improving our service to be
better and more user friendly.

Czyli w skrócie “nie powiemy bo jeszcze nie wiemy”

A na dodatek dziwnym trafem informacja “Reminder” jakoś zniknęła z panelu

Dodaj posta do:

PIM Backup

Dodaj posta do:

 http://www.debugmode.com/wink/

Dodaj posta do:

http://technet.microsoft.com/pl-pl/sysinternals/bb896645(en-us).aspx

Dodaj posta do:

Kilka informacji podstawowych -> Raporty na serwerze raportów zwykle mają zdefiniowany plik Data source zawierający informacje o połączeniu do bazy danych. Tak dla ułatwienia, żeby nie trzeba było dla każdego raportu wpisywać tych informacji. W Data Source definiuje się także sposób połączenia do bazy. Najprościej jest wykorzystać autentykację windows, czyli na podstawie uprawnień użytkownika domenowego. Niestety to nie jest takie proste. O tym dalej.

Załóżmy, że użytkownik domenowy, który wyświetla raport (*może to być użytkownik na prawach którego działa aplikacja ASP, która korzysta z kontrolki do wyświetlania raportu) ma prawa do tego raportu jak i do bazy danych, z której ten raport bierze dane. Skoro raport działa z uprawnieniami użytkownika (autentykacja Windows, czyli domenowa) no to wszystko gra. Ma prawa do tego, co trzeba. No nie do końca. Pojawia się błąd:
“An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘DS1′. (rsErrorImpersonatingUser)
Logon failed. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors ”

Można sobie włączyć Remote errors (http://technet.microsoft.com/en-us/library/aa337165.aspx) ale niewiele to daje. Dodatkowa informacja to:

“Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0×80070569)”

Pierwsza przeszkoda

Aby możliwe było użycie Data Source na prawach użytkownika domenowego, ten użytkownik musi mieć prawo “Allow log on locally” (Zezwalaj na logowanie lokalne) na komputerze na którym działa Reporting Services. To prawo musi mieć użytkownik, który “wyzwala” Data source. Można także w konfiguracji Reporting Services (Start -> programy -> Microsoft SQL Server 2005 -> configuration tools -> Reporting Services Configuration) ustawić “Execution account” i tam wpisać użytkownika, który takie prawo będzie posiadał . W ten sposób Reporting Services będzie mogło wywoływać wszystkie data source. Jest do dokładniej opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326317.aspx

Druga przeszkoda

Chcieliśmy ustawić aby Reporting Services działały na zasadzie autentykacji windows. Daje to tyle ze aplikacja webowa IIS (w tym przypadku Reporting Services) może działać z uprawnieniami użytkownika domenowego, który z niej korzysta. Wszystko jest w porządku dopóki serwer IIS na podstawie tych danych uwierzytelniania spróbuje się dobrać do innych zasobów sieci (np. serwera MS SQL). Nie jest dopuszczalne takie zachowanie. Aplikacja nie możę korzystać z uprawnień tego użytkownika w innych usługach. Uznano, że to zbyt duże uprawnienie nadane aplikacji. Użytkownik musi wiedzieć do czego będą użyte jego uprawnienia. Ten problem nazwano “double hop”. Pierwszy hop to połączenie między użytkownikiem a IIS, a drugi hop to połączenie pomiędzy IIS a SQL serverem. Tego nie można zrobić. Jest to opisane tutaj: http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx Tak naprawdę użytkownik daje prawo aplikacji do działania z jego uprawnieniami tylko na poziomie serwera IIS.

* Kilka użytecznych definicji i wyjaśnień można znaleźć tutaj: http://msdn2.microsoft.com/en-us/library/aa480547.aspx

Można to obejść w różny sposób.

1. W data source w Reporting Services wpisać nazwę użytkownika i hasło do połączenia z bazą danych (Stored Credentials). Hasło będzie zaszyfrowane w bazie danych Reporting Services (dla jasności: Reporting Services ma własną bazę danych do przechowywania raportów i innych rzeczy) .
Raczej nie ma możliwości zapisania nazwy użytkownika i hasła Data Source w rejestrze tak jak to można zrobić z aplikacją ASP. Jedynie można impersonifikować całą usługę Reporting Services, tak jak zostało to opisane tutaj: http://msdn2.microsoft.com/en-us/library/bb326419.aspx
2. Można zezwolić serwerowi IIS na “drugi hop” zgodnie z :

http://support.microsoft.com/default.aspx?scid=kb;en-us;810572

Czyli trzeba by było zmienić ustawienia active directory, aby ufać serwerowi IIS jeśli chodzi o delegowanie uprawnień (drugi hop):
http://msdn2.microsoft.com/en-us/library/ms916706.aspx

Minus jest taki, że trzeba by było zmienić ustawienia komputerów klienckich zgodnie z pierwszym podanym przeze mnie linkiem. Poza tym może to w jakimś stopniu obniżyć bezpieczeństwo, bo skoro serwer IIS będzie miał pozwolenie na delegowanie uprawnień, no to wszystkie aplikacje (nie tylko Reporting Services) będą mogły z tej opcji korzystać. Niby klient (Internet Explorer) musi pozwolić na delegowanie jego uprawnień, ale i tak może to być problem.

Mam nadzieję, że ten post zaoszczędzi komuś czas Dzięki temu problemowi zdecydowanie poprawiłem sobie znajomość zagadnień związanych z ASP i uprawnieniami domenowymi, choć nie ukrywam, że wolałbym spędzić nad tym mniej czasu

Dodaj posta do:

1. Przekierowywanie przez mod_rewrite

Musimy stworzyć na serwerze plik o nazwie .htaccess (w katalogu głównym) i wpisać do niego:

Options +FollowSymLinks
RewriteEngine On

# przypadek strona.com

RewriteCond %{HTTP_HOST} ^strona.com [NC]
RewriteRule ^(.*)$ http://www.strona.com/$1 [R=301,L]

#przypadek www.strona.pl

RewriteCond %{HTTP_HOST} ^www.strona.pl [NC]
RewriteRule ^(.*)$ http://www.strona.com/$1 [R=301,L]

I tak dalej dla reszty adresów. Pewnie by się dało wszystko w jednej linijce, ale mi tak wystarczy Do pisania reguł mod_rewrite przydaje się znajomość wyrażeń regularnych. Przykłady zastosowań mod_rewrite można znaleźć na stronie: mod_rewrite Cheat Sheet.

2. Przekierowywanie przez php

Można użyć także php np. tak:

<?
//przypadek strona.com
$host=$_SERVER["HTTP_HOST"];
if ( $host == “strona.com” ) {
$location=”http://www.strona.com”.$_SERVER["REQUEST_URI"];
header( “Location: $location” );
exit();
}

//przypadek www.strona.pl
if ( $host == “www.strona.pl” ) {
$location=”http://www.strona.com”.$_SERVER["REQUEST_URI"];
header( “Location: $location” );
exit();
}
?>

Nie podaję tutaj, jak zrobić przyjazne adresy w PHP bo tego nie testowałem. Można sobie to wygooglować

Przyjazne adresy URL

Drugim naszym zadaniem jest utworzenie przyjaznych adresów podstron. Załóżmy że nasza strona ma adresy podstron w postaci: www.strona.com/main.php?strona=oferta Po pierwsze nie wygląda to najpiękniej, a po drugie mniej się to podoba googlowi. Użyjemy mod_rewrite aby to poprawić. Zamienimy podany wcześniej adres na taki oto adres: www.strona.com/nasza_wspaniala_oferta

Zawartość .htaccess :

Options +FollowSymLinks
RewriteEngine On

RewriteRule ^nasza_wspaniala_oferta $ main.php?strona=oferta [L]

I gotowe. Teraz możemy w kodzie naszej strony używać przyjaznych linków i zyskamy lepsze wyszukiwanie w google.

Dodaj posta do:

Poza tablicami dla BPMN są jeszcze tablice dla ITIL, Prince2, UML i innych zagadnień. Ciekawy pomysł.

Dodaj posta do: