Può capitare, avendo un sito web composto da diverse directory o sottodirectory, di dover consentire l’accesso ad una particolare directory solamente ad alcuni utenti. Avendo un web server come Apache su piattaforma Linux (le informazioni indicate di seguito le ho provate su una Debian Etch), è possibile utilizzare un file .htaccess, da creare nella directory a cui si vuole limitare l’accesso, per raggiungere lo scopo prefisso.

Il primo passo consiste appunto nella creazione del file .htaccess e nell’assegnazione dei corretti permessi al file stesso:

# touch /var/www/sito/dirProtetta/.htaccess
# chmod 644 /var/www/sito/dirProtetta/.htaccess

Fatto questo, editare il file .htaccess col proprio editor preferito inserendo queste righe:

AuthName “Area protetta”
AuthType Basic
AuthUserFile /var/www/sito/dirProtetta/.htpasswd
Require valid-user

L’istruzione nella prima riga rappresenta il titolo della finestra di richiesta autenticazione, la seconda riga indica invece il tipo di autenticazione alla directory, cioé l’autorizzazione di tipo Basic, che consente il passaggio in chiaro del traffico di autenticazione, a differenza dell’autenticazione di tipo Digest; la terza riga specifica il percorso del file .htpasswd, che altri non è che il file contenente le accoppiate username -> password degli utenti a cui è consentito autenticarsi. Di seguito abbiamo il tag , con gli attributi GET, PUT e POST che rappresentano le operazioni consentite in relazione alla directory (rispettivamente download, upload e invio informazioni tramite form), al cui interno vi è l’istruzione “Require valid-user” che dice ad Apache di consentire l’accesso alla directory solamente agli utenti riconosciuti come validi, cioé che hanno fornito le corrette credenziali d’accesso.

Eseguiti questi passaggi, bisogna creare gli utenti del caso tramite il comando htpasswd. La creazione del primo utente comporta anche la creazione del file .htpasswd, tramite questo comando:

# htpasswd -c /var/www/sito/dirProtetta/.htpasswd utente1

Digitato questo comando, verrà chiesta per due volte la password da assegnare all’utente, e contestualmente verrà creato il file .htpasswd nella directory specificata con l’opzione -c; a questo file vanno assegnati adeguate autorizzazioni, in particolare il gruppo www-data (il gruppo che contiene l’utente omonimo che esegue il demone apache2) dovrà poter accedere al file almeno in lettura:

# chown root:www-data /var/sito/dirProtetta/.htpasswd
# chmod 640 .htpasswd

Ora possiamo creare gli altri utenti in questo modo:

# htpasswd /var/www/sito/dirProtetta/.htpasswd utente2

Creati gli utenti, abbiamo fatto quasi tutto; l’ultimo passaggio consiste nel modificare la configurazione di Apache in modo tale che sia consentito l’accesso ai file .ht per la directory che vogliamo proteggere, infatti, almeno in Debian (non so se è così anche con altre distribuzioni), l’accesso ai file .ht è inibito per default, quindi bisogna dire ad Apache che vogliamo sovrascrivere questa impostazione limitatmente alla directory specifica. In particolare, cercare all’interno del file /etc/apache2/apache2.conf il tag in modo tale che la configurazione finale sia questa:
Order allow,deny
Deny from all
AllowOverride AuthConfig Limit

dove il tag rappresenta appunto la sovrascrittura delle impostazioni date all’interno del tag .

Risulta essere tutto, ora quando un utente accede a questa particolare directory del sito si ritroverà davanti alla richiesta di inserimento di username e password che Apache dovrà autenticare o meno.

Sky è oggi uno dei mezzi più utilizzati per guardare film, sport, documentari e tantissime cose ancora. Vi è mai capitato di essere fuori casa e non poter seguire sul vostro sky la vostra squadra del cuore o un film.

Un vero dilemma direste, ma avete un iPhone un computer portatile o uno smartphone con connessione ad internet. Con l’applicazione Skygo potrete vedervi tutti i programmi vostri preferiti ovunque voi siate purchè abbiate ovviamente la connessione ad internet e l’abbonamento a sky.

Dopo avere scaricato l’applicazione ed aperto il programma, ci troveremo davanti dei tasti ognuno con una propria funzione.

Ovviamente nel pulsante di login dovreste mettere le vostre informazioni sul nick e password relative all’abbonamento Sky.

Nel pulsante impostazioni troveremo un menù nel quale andrà inserito il numero della tessera personale Sky, e da quì possiamo personalizzare diverse cose, come ad esempio il canale Sky predefinito, filtro canali, promemoria per un evento.

Come nei browser la stella ci da la possibilità di inserire tra i preferiti il canale. Invece in basso a destra, ci sarà una freccia che ci darà tutti i canali disponibili con i relativi programmi in onda.

Dopo avere illustrato brevemente il programma, è ora di passare alla fase più importante, l’attivazione.

La prima cosa da fare è andare sul sito di Sky effettuare il login e andare nell’Area Clienti, selezionare la scheda fai da te e mettere username e password.

Premere invia, e una volta fatto ciò tornare sulla scheda area clienti e su fai da te, premere arricchisci abbonamento, andare nella sezione per te e selezionare la scheda Decoder e Servizi.

Da quì si può controllare se l’attivazione è avvenuta con successo, guardando in basso La composizione del tuo abbonamento è.

Adesso la cosa da fare è procuraci il player, installeremo infatti il plug in SkyGo Player seguendo passo passo le istruzioni dopo il login su SkyGo, ricordiamoci che possono essere abilitati due device per visualizzare i canali live di SkyGo sul nostro computer.

Dal sito di sky se proviamo a collegarci su sky go e cliccare uno dei canali, ci dirà che abbiamo bisogno di Sky Go Player quindi installiamolo.

A questo punto non ci rimane che goderci nei nostri smartphone tablet ovunque noi desideriamo, i nostri programmi preferiti quando ci pare e piace, in qualunque posto noi ci troviamo.

In caso di problemi, è possibile seguire questa guida sul servizio clienti Sky per contattare l’azienda e trovare una soluzione.

Quando si realizza una pagina di caricamento file (upload) in ASP, intervengono diversi fattori che determinano il successo o meno del caricamento, in particolare, con file piuttosto grandi, è possibile avere dei problemi che possono dipendere dal fatto che, passato un determinato periodo di tempo, lo script ASP va in timeout prima che il file sia stato caricato completamente sul server Web, oppure, un altro fattore che entra in gioco è la dimensione massima del file che può essere caricato su un server Web.

Per quanto riguarda la regolazione del timeout dello script, è possibile utilizzare la proprietà Server.ScriptTimeout, che indica il tempo massimo – espresso in secondi – a disposizione dello script per la sua completa esecuzione, secondo questa forma:

Server.ScriptTimeout = 300

Con l’esempio indicato, uno script andrà in timeout dopo 300 secondi, ossia dopo 5 minuti.

La dimensione massima caricabile su un server Web IIS 6.0 su Windows Server 2003 invece va regolata editando il file c:\windows\system32\inetsrv\metabase.xml e impostando il valore del parametro “AspMaxRequestEntityAllowed”, che assume il valore predefinito di 204800 byte (200Kbyte), alla dimensione desiderata, espressa sempre in byte. L’editing diretto di questo file però non è consentito se IIS è attivo, ma comunque è possibile modificare questo valore tramite l’esecuzione di uno script VBS in grado di variare questo parametro, seguendo questa sintassi:

cscript adsutil.vbs set w3svc/ASPMaxRequestEntityAllowed dimensione

dove al posto di dimensione va indicata la massima dimensione in byte consentita per i file caricati tramite upload. Fatta questa modifica va riavviato il servizio iisadmin tramite la console di gestione dei servizi di Windows Server oppure tramite il comando iisreset. Fatta questa operazione, la modifica è attiva ed è operativo il nuovo limite di caricamento file sul server.

In una rete con un server di dominio Windows Server 2003 è indispensabile un corretto funzionamento del servizio DNS, onde evitare problemi nell’utilizzo dei servizi di autenticazione e dei normali servizi di rete erogati su una LAN, poiché Active Directory (da ora in poi AD) si basa su DNS per il proprio funzionamento, senza contare che la risoluzione dei nomi host dei PC in rete viene realizzata sempre tramite DNS. Per evitare di dover gestire a mano tutte le corrispondenze nome host -> indirizzo IP, il servizio DNS integrato in Windows Server 2003 supporta gli aggiornamenti dinamici dei record di risorse dell’host (A) – cioè dei record memorizzati nelle zone di ricerca diretta – e dei record di risorse del puntatore (PTR) – i record memorizzati nelle zone di ricerca inversa – da parte dei client della rete a partire da Windows 2000. In questo modo, quando avvengono dei cambi di nomi host o dei cambi di PC sulla rete locale, non è necessario cambiare a mano i record presenti sul server DNS, poiché gli aggiornamenti sono automatici.

Se nella rete abbiamo un server DHCP (come accade nella stragrande maggioranza delle reti, pratica comunque sempre condivisibile a mio parere), dobbiamo accertarci che questo supporti gli aggiornamenti dinamici dei record DNS, ovviamente, se usiamo il server DHCP integrato in Windows Server, non avremo problemi, visto che per impostazione predefinita, quando rilascia un lease ad un client, si occupa di aggiornare le zone diretta ed inversa del dominio AD coi corrispondenti record (A) e (PTR); a tal riguardo, bisogna fare attenzione a non avere attivo un server DHCP su altri dispositivi presenti in rete (come un router) che potrebbe creare conflitti con il server DHCP installato sul server, infatti in questi casi la cosa migliore è utilizzare l’accoppiata server DNS – server DHCP già presenti sul Windows Server 2003.

Quando un client cambia il proprio nome oppure quando viene registrato nel dominio, il servizio DHCP Client fa una query di tipo SOA al proprio server DNS primario, e se riceve una risposta affermativa, tenta di contattare il server DNS restituito come risultato dell’interrogazione per fornirgli un aggiornamento dinamico che includa il nuovo valore dell’accoppiata nome host -> indirizzo IP come record (A) e (PTR), ed inoltre, contestualmente e se necessario, rimuova la vecchia accoppiata nome host -> indirizzo IP dalla “forward zone” e dalla “reverse lookup zone” di AD.

Se in una rete è attivo un server DHCP su un controller di dominio, allora può essere lo stesso server DHCP a farsi carico di aggiornare dinamicamente il server DNS per conto dei client; ciò è indispensabile in quanto può succedere in qualsiasi momento che un server DHCP cambi l’assegnazione dell’indirizzo IP ad un client, ed è quindi di fondamentale importanza che vengano aggiornati i record (A) e (PTR) relativi al client sul server DNS, altrimenti la macchina non sarà contattabile in rete locale. Per forza di cose quindi il server DHCP di Windows Server 2003 è configurato per aggiornare dinamicamente il server DNS in modo predefinito, ma solamente per quei client che richiedono in modo predefinito l’aggiornamento dinamico, cioé che hanno come sistema operativo Windows 2000, Windows XP o Windows Server 2003 (e presumo anche Windows Vista). Come comportamento predefinito, quando un client riceve un lease dal server DHCP, il client cercherà di aggiornare il record di risorse dell’host (A), mentre il server DHCP tenterà di aggiornare il record di risorse del puntatore (PTR). Per controllare le impostazioni concernenti gli aggiornamenti dinamici da parte di client e server DHCP, cliccare col tasto destro sul server DHCP in MMC e andare su Properties, quindi cliccare sulla scheda DNS.

Sempre parlando della configurazione predefinita dei server DNS e DHCP in Windows Server 2003, bisogna considerare che gli aggiornamenti dinamici del server DNS avvengono per default in modalità protetta per le zone integrate in AD, ciò significa che solamente i client ed i server facenti parte del dominio AD possono effettuare aggiornamenti dinamici sul server DNS. In questa situazione, è necessario creare un account utente di AD che verrà utilizzato dal servizio DHCP server per aggiornare dinamicamente il server DNS, ed impostarlo effettivamente per questo compito, andando sempre in console MMC di DHCP, quindi cliccando col tasto destro sul server, Properties, Advanced, cliccare sul pulsante Credentials, e comparirà una maschera dove inserire il nome utente dell’account di cui sopra, il dominio di appartenenza e la relativa password. Tenere presente inoltre che l’account dedicato va creato anche quando il servizio DHCP è attivo su un controller di dominio (situazione tipica presente su piccole reti) e quando è il servizio DHCP che registra gli aggiornamenti dinamici per conto dei client, in parole povere, questo account va impostato nelle situazioni più comuni di funzionamento di Windows Server 2003.

Se si vuole sincronizzare l’ora del nostro domain controller (DC) con un time server esterno per avere sempre l’ora corretta impostata su tutto il dominio, i passi da compiere sono pochi e semplici. La sincronizzazione avviene per mezzo del protocollo NTP, che serve proprio a questo scopo.

Per sincronizzare l’ora del server, basta digitare questi due semplici comandi:

w32tm /config /syncfromflags:manual /manualpeerlist:time.ien.it,www.clock.org
w32tm /config /update

Da notare l’ultimo parametro del primo comando, /manualpeerlist, dove di seguito sono indicati due time server tramite i quali sincronizzare la nostra rete locale, o meglio, si sincronizza l’ora del server, il quale a sua volta funge da time server per i client della rete.

Molto interessante.