La expansión continuada de los recursos telemáticos facilita cada vez más la creación de sistemas electrónicos de información y de comunicación. A este fenómeno no permanece ajena la Universidad de Córdoba, para la que los recursos telemáticos son, frecuentemente, su principal y primera vía de acceso al exterior. En efecto, los centros, los departamentos, los distintos servicios y, con carácter general, todas las unidades y estructuras de la Universidad exponen su información y se presentan ante los usuarios del servicio y la sociedad en general a través de páginas web, todas ellas vinculadas a servidores de la Universidad.
En este sentido, la Web de la UCO está formada por páginas con contenidos de información institucional, comprendiendo entre otros aspectos, la difusión de información de la actividad académica, docente, investigadora, de transferencia, divulgadora, de extensión universitaria o de cualquier índole relacionada con las funciones que le son propias. El contenido de estas páginas, desplegado de forma clara, estructurada y jerarquizada, representa la visión institucional de la UCO, tanto al interior de la red propia (INTRANET) como en el exterior (INTERNET). Estas páginas son:
a) La página principal (home page) y otras páginas institucionales que recogen información general o transversal de la universidad, las cuales estarán editadas principalmente por el Gabinete de Comunicación y otros servicios centrales.
b) Las páginas vinculadas, editadas por cualquier Centro, órgano o unidad organizativa de la universidad, reconocida en el nomenclátor de la UCO, que recogen información relativa al ámbito de competencia de la unidad organizativa correspondiente, sin perjuicio de que la página tenga otras formas de acceso adaptadas al perfil del usuario.
Dado el carácter universitario público de nuestra institución, y a su primordial función de servicio público, es necesario garantizar la debida adecuación de los contenidos informativos a las necesidades de nuestra comunidad universitaria y de la sociedad a la que servimos, respetando los derechos individuales y colectivos generales y los principios y los fines fundacionales de nuestra universidad, sin dejar de lado la calidad de la información difundida y su exposición. Por este motivo, y teniendo que la comunicación y difusión de la información institucional se hace necesariamente de forma descentralizada por las diversas estructuras universitarias, es imprescindible también establecer mecanismos de coordinación entre todas ellas. Solo de este modo será posible garantizar la calidad del servicio y un uso del mismo de acuerdo a los fines propios de la Universidad como Administración pública.
Al amparo del artículo 119 de los Estatutos de la Universidad de Córdoba, las personas titulares de los Vicerrectorados, la Secretaría General y la Gerencia de la Universidad de Córdoba podrán, en el ámbito de sus respectivas competencias, aprobar Circulares e Instrucciones dirigidas al personal de los servicios, centros y estructuras de la Universidad, dándoles instrucciones sobre su actuación o estableciendo mecanismos de coordinación.
Por su parte, la Resolución de 11 de julio de 2018, de la Universidad de Córdoba, sobre estructura y determinación de los Vicerrectorados, de las Delegaciones, y del régimen de delegación en competencias, delega en el Vicerrectorado de Coordinación, Cultura y Comunicación la coordinación de la divulgación y comunicación institucional, así como la imagen corporativa.
En atención a todo lo anterior, dicto las siguientes instrucciones, dirigidas a todas las estructuras y unidades de la Universidad de Córdoba que hospeden o gestionen páginas web institucionales, tengan estas carácter permanente o temporal.
1. Unidades y estructuras que podrán alojar páginas web institucionales de la Universidad de Córdoba
1. La persona responsable, que deberá tener una dirección de correo electrónico de la Universidad de Córdoba, realizará las tareas de edición, publicación y mantenimiento de los contenidos web del hospedaje.
2. Para atender consultas y sugerencias se creará un alias de correo asociado al huésped, y será el que se utilice en las páginas del servidor Web. Todos los mensajes que se reciban en esta dirección se reenviarán al buzón personal del responsable.
Si el mantenimiento de los contenidos se externaliza por decisión del responsable de la misma, dicho mantenimiento deberá observar estrictamente las presentes instrucciones. La responsabilidad del correcto uso de la página seguirá recayendo en la persona responsable.
3. Cualquier cambio en la situación del responsable del hospedaje (baja, cese o sustitución) deberá ser comunicado de inmediato al Gabinete de Comunicación.
4. Si una página no correspondiente al menú principal y sus enlaces desplegables, a un Centro, Servicio o Unidad queda sin responsable, dicha página será eliminada. Igualmente, aquellas páginas no actualizadas en el periodo de un año, y previa información al responsable, serán igualmente eliminadas de no solventarse dicha situación.
2. Información que podrá ser objeto de publicación
1. La página web de la Universidad de Córdoba es www.uco.es y en ella se difunde información institucional de la Universidad.
2. A efectos de su difusión, se entenderá por información institucional la información generada por cualquier órgano o unidad organizativa de la universidad, tanto académica, de investigación, administrativa, o de extensión universitaria en el ejercicio de sus funciones y dentro de su ámbito de competencia.
3. La información difundida en la web de la UCO ha de ajustarse a las siguientes características:
a) Debe ser información institucional veraz, precisa y actualizada.
b) No podrán ser utilizados materiales que tengan derechos de autor, salvo que se tenga autorización explícita del titular.
c) No podrá incorporar publicidad salvo que cuente con la autorización expresa de la Gerencia.
d) La información debe garantizar el derecho a la intimidad y a la propia imagen de las personas.
4. Las páginas web de la Universidad de Córdoba respetarán la imagen corporativa de la misma, debiendo toda la información publicada en la Web observar el Manual de Imagen Corporativa de la UCO vigente en cada momento.
5. Todas las páginas identificarán claramente el nombre del editor de la información, considerando una buena práctica la publicación de la fecha de creación y/o actualización de la información editada.
6. En caso de concurrencia de información editada por dos o más servidores de información, el Gabinete de comunicación resolverá sobre la publicación y condiciones de la misma.
3. Procedimiento de solicitud de páginas web por parte de unidades administrativas
1. La solicitud de espacios web, que se remitirá al Gabinete de comunicación, será informada por el Servicio de Informática, y deberá contener, al menos, la siguiente información:
a) Datos del solicitante, indicando el cargo ostentado o responsabilidad en el servicio o unidad administrativa correspondiente.
b) Tipo de web, indicando si es para centros, servicios, departamentos, proyectos de Investigación, master, cátedras y Aulas, grupos de docencia, grupos de mejora docente, congresos y eventos temporales, otros, etc.
c) Descripción de la web solicitada.
d) Nombre o acrónimo para usar en la dirección web. Se deberán evitar los nombres que puedan entrar en conflicto con otros dominios institucionales y los muy genéricos que sean susceptibles de ser usados por distintos estamentos dentro de la UCO.
e) Alias de dirección web que permitirá una dirección a primer nivel, del tipo www.uco/xxxxx. La activación de este alias estará sujeta a informe previo del gabinete de comunicación.
f) Tipo de software utilizado o tecnología usada para la confección de la página si es conocido de antemano. Esto permitirá al Servicio de Informática adaptar los parámetros del sistema para un funcionamiento más eficiente.
g) Base de datos asociada si es necesaria
h) Adicionalmente, y para el caso de solicitar que la dirección apunte a un servidor fuera de la red UCO, deberá presentarse una solicitud a este fin que deberá ser aceptada por el Gabinete de comunicación. En caso de aceptarse, deberá adjuntar también una declaración firmada por el responsable de la web sobre el contenido y propósito de la misma, y que exima a la Universidad de cualquier responsabilidad sobre el mantenimiento, disponibilidad y accesibilidad de la misma.
2. Las webs de información externa a nuestros servidores deberán tener los siguientes requisitos para poder ser vinculadas dentro la web de la UCO:
a) Deberán cumplir la presente circular en lo que les sea de aplicación.
b) Deberán ser estables y funcionar las 24 horas del día.
c) La portada de la web vinculada dispondrá de un enlace con la página principal (home page) de la web de la UCO.
3. La Universidad de Córdoba centraliza toda su información web a través del portal www.uco.es y sus equivalentes (actualmente uco.es, uco.eu, uco.edu.es, uco.com.es y uco.org.es). En consecuencia, no se contempla el uso de direcciones xxx.uco.es salvo que sean estrictamente necesarios por motivos técnicos, debiendo estar estos sitios convenientemente enlazados por la dirección www.uco.es/xxxx, y que debe ser la que se publicite externamente.
No obstante, los nombres de dominio concedidos previamente a la entrada en vigor de esta normativa podrán seguir usándose o adaptarse a los nuevos criterios recogidos en estas directrices.
4. La decisión sobre la concesión de la página web la adoptará el Vicerrectorado competente en Comunicación.
4. Confección de páginas web y soporte técnico
1. La Universidad de Córdoba, a través de su Servicio de Informática, proveerá los recursos necesarios así como las plantillas para confeccionar las webs, establecerá los requisitos técnicos para la confección de páginas y a través del Servicio de Informática podrá participar en la formación de usuarios en las técnicas de creación de páginas web.
2. El Gabinete de Comunicación atenderá a los responsables y los editores de páginas vinculadas en los aspectos relacionados con la elaboración y estructuración de la información descentralizada. Determinará también en cada caso el aspecto común y contenidos mínimos de información.
5. Puesta en marcha y publicidad
1. Una vez finalizada la confección de la página, el responsable lo comunicará al Gabinete de comunicación para confirmar su adecuación a la normativa, su activación final y vinculación en los menús apropiados del servidor Web.
2. Para aquellas unidades o estructuras que necesiten publicación de novedades periódicamente el Gabinete de comunicación podrá autorizar al usuario responsable de la página para la inserción de novedades en el boletín diario.
6. Responsable de la página web
1. Cada espacio web dispondrá de un responsable técnico, cuya función será mantener los recursos en condiciones adecuadas de funcionamiento, velando por la disponibilidad del servicio y por el correcto uso de los recursos de la UCO.
Asimismo, el responsable técnico debe garantizar que los recursos presentan un funcionamiento seguro que no interfiera en el uso del resto de la red universitaria.
2. Los contenidos de cada espacio web estarán bajo la responsabilidad de la persona designada en el formulario de solicitud de alta en el servicio.
3. El cese o sustitución del responsable de contenidos deberá ser comunicado al Gabinete de Comunicación, y éste al Servicio de Informática, que dispondrá de un listado actualizado de responsables de las páginas alojadas en la web de la Universidad de Córdoba
Los servicios webs corporativos dependientes de responsables asociados a cargos específicos deberán notificar cualquier cambio relativo a la responsabilidad del sitio web por motivo de cese o extinción de su cargo, traspasando toda información y responsabilidad al nuevo cargo, siendo este notificado de su nuevo estado.
4. El responsable del espacio web lo es de todo el contenido que se exponga en la página que administra, y debe por ello hacerse igualmente responsable de la custodia de la clave de acceso que le permite publicar dichos contenidos.
7. Mantenimiento y cancelación de páginas web
1. Los hospedajes deberán ser actualizados, al menos, una vez durante el año académico. Asimismo, se establecerán periodos de renovación del mismo que serán comunicados a la persona responsable. Esta dispondrá de 1 mes para confirmar la "renovación", en caso contrario se cancelará el servicio.
2. L a Universidad podrá suspender temporalmente o cancelar aquellas páginas web que no cumplan lo establecido en estas instrucciones o que no se ajusten a las prescripciones técnicas establecidas por el Servicio de Informática. También podrá suspender o cancelas las páginas web por motivos de seguridad, por un mantenimiento inadecuado del programa empleado para su confección, cuando su uso afecte a la seguridad del servidor o a la reputación externa de nuestros servidores.
3. Se podrán asimismo establecer aquellas limitaciones técnicas que el Servicio de Informática considere oportunas para un mejor desarrollo del servicio.
4. El Servicio de Informática realizará copias de seguridad periódicas de los contenidos alojados en sus servidores. El Servicio de Informática mantendrá información actualizada sobre el alcance de esta política.
Luis M. Medina Canalejo
EL VICERRECTOR DE COORDINACIÓN,
CULTURA Y COMUNICACIÓN
These instructions let you get a minimal installation of
PAPI up and running quickly in a modern Debian/Ubuntu system.
For sake of simplicity, we assume you are installing both
PAPI components (AS and PoA), althouh later we show you
how to configure each, maybe in different computers. We
use the names 'ashost' and 'poahost' as examples. Both may be the
same (localhost, for instance). We will use <Location> directives
although using virtual hosts is usually better.
These instructions make use of the WAYF (Where Are You From)
capability of PAPI. It means that when you try to access a protected
resource (PoA), you are redirected to the AS to authenticate first, then
you are returned to the PoA, where you (most probably in real life,
certainly in this example) will be granted access. There is other way
it works: yoy may access the AS for the first time, and after successfully
authentication you will be presented a list of PoAs you can access (you
can call this the 'portal mode').
$ cd $BUILDDIR
$ tar xzf PAPI-1.4.1.tar.gz
$ cd PAPI-1.4.1
$ perl Makefile.PL
...
You must provide a location for installing the PAPI Authentication
Server software. It must be a directory configured to hold CGI
programs in your Apache installation [/usr/local/apache/cgi-bin]
-> /usr/lib/cgi-bin
...
The program was not able to determine a location for your OpenSSL
installation, required to build PAPI. Please type the full path to
the OpenSSL directory [/usr/local/ssl]
-> /usr
...
* If there are messages about missing Perl modules, install them and do
it again (you can skip the module Athens::DA if interaction with Athens
is not a requirement for you).
* If you don't have CGI::Lite, install it (necessary for the AS)
* Usually, this is necessary (for the PoA):
$ ln -s /usr/include/apache-1.3 /usr/include/apache
$ make
$ make install
* It will install:
/usr/lib/cgi-bin/{AuthServer,AuthServer.cf}
/usr/local/lib/perl/x.y.z/PAPI/*
/usr/local/lib/perl/x.y.z/auto/PAPI/*
/usr/bin/{pdimport,pdexport}
and several man pages
** In the AS (assuming it's ID will be 'MyAS'):
$ mkdir -p /usr/local/PAPI/AS/etc
$ cp $BUILDDIR/PAPI-1.4.1/AS/etc/*html /usr/local/PAPI/AS/etc
$ cp $BUILDDIR/PAPI-1.4.1/AS/etc/Basic.sample.src /usr/local/PAPI/AS/etc/Basic.src
* Now, generate a pair of public/private keys:
$ openssl genrsa -out MyAS_privkey.pem 1024
$ openssl rsa -in MyAS_privkey.pem -pubout -out MyAS_pubkey.pem
$ mv MyAS_privkey.pem /usr/local/PAPI/AS/etc
* Send the MyAS_pubkey.pem to all the servers with PoAs that are going
to use our AS (in these systems it must be installed as
/usr/local/PAPI/PoA/KEYS/MyAS_pubkey.pem).
If you are going to configure a PoA in this system:
$ mkdir -p /usr/local/PAPI/PoA/KEYS
$ cp MyAS_pubkey.pem /usr/local/PAPI/PoA/KEYS/MyAS_pubkey.pem
* Edit /usr/lib/cgi-bin/AuthServer.cf:
- Make sure this line exists:
use PAPI::BasicLog;
$$cfg{workingDirectory} = '/usr/local/PAPI/AS/etc';
# This SHOULD be https, but for testing you can use http
$$cfg{asLocation} = 'http://ashost/cgi-bin/AuthServer';
$$cfg{serverID} = 'MyAS';
$$cfg{privateKey} = 'MyAS_privkey.pem';
- Generate this value using, for example, md5sum:
- cat `find /var/tmp -type f -print` | md5sum | cut -c1-32
$$cfg{symKey} = "................................"
- For the first tests:
$$cfg{basicAuthDB} = "Basic.pdb"
...
$$cfg{authenticationHook} = \&PAPI::BasicAuth::VerifyUser;
$$cfg{credentialHook} = \&PAPI::BasicAuth::AllSites;
$$cfg{attrRequestHook} = \&PAPI::BasicAuth::AllSiteAttributes;
With BasicAuth, all is configured in a simple file: Basic.pdb
- You can leave these commented out. They are tipically defined to
- point to red and green balls when you use the 'portal' mode instead
- of WAYF, as we do in this sample setup.
#$$cfg{acceptURL} = 'http://as.papi.dom.ain/accept-file';
#$$cfg{rejectURL} = 'http://as.papi.dom.ain/reject-file';
- For the first tests, you can comment:
#$$cfg{splitModeURL} = ...
#$$cfg{splitModeParamList} = ...
- Logging:
$$cfg{logHook} = \&PAPI::BasicLog::FileLog;
$$cfg{logFile} = "/var/tmp/PAPIAS.log";
* Define at least one user and one site (PoA)
BasicAuth uses
In /usr/local/PAPI/AS/etc/Basic.src append these lines
IMPORTANT: Change 'poahost'! It must match the name you use to access
the PoA:
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
# User 'papitest', password: 'papitest'
user::papitest::hw0rgZVZz0QRs::::::
#
site::PAPI_test_site::PAPI Test site::http://poahost::/PAPI/cookie_handler.cgi::1800::TestPoA::/papi::index.html::
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
$ cd /usr/local/PAPI/AS/etc
$ pdimport -n -s Basic.src Basic.pdb
** In the PoA:
If you didn't this before:
- mkdir -p /usr/local/PAPI/PoA/KEYS
- mv ..../MyAS_pubkey.pem /usr/local/PAPI/PoA/KEYS
(The name *MUST* be the ID of the AS with "_pubkey.pem" appended).
- ps -ef | md5sum | cut -c1-32 > /usr/local/PAPI/PoA/lkey
- cat /var/log/messages | md5sum | cut -c1-32 > /usr/local/PAPI/PoA/hkey
- chown -R www-data /usr/local/PAPI
- Configure one simple PoA. At the end of /etc/apache/httpd.conf:
include "papi.conf"
- Contents of the file /etc/apache/papi.conf (change 'ashost'):
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
PerlModule PAPI::Conf
<PAPI_Main>
Service_ID test_PoA
Debug 1
HKEY_File /usr/local/PAPI/PoA/hkey
LKEY_File /usr/local/PAPI/PoA/lkey
Lcook_Timeout 60
CRC_Timeout 30
URL_Timeout 200
Auth_Location /PAPI/cookie_handler.cgi
Accept_File /usr/local/PAPI/PoA/blueball.png
Reject_File /usr/local/PAPI/PoA/redball.png
Pubkeys_Path /usr/local/PAPI/PoA/KEYS
Hcook_DB /usr/local/PAPI/PoA/hcook.db
PAPI_AS MyAS http://ashost/cgi-bin/AuthServer Test AuthServer
</PAPI_Main>
<Location /papi>
PerlSendHeader On
PerlAccessHandler PAPI::Main
<PAPI_Local>
Service_ID TestPoA
GPoA_URL wayf:built-in
Req_DB /usr/local/PAPI/PoA/req_TestPoa
</PAPI_Local>
</Location>
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
* In the PoA server (poahost), create the protected pages:
$ mkdir /var/www/papi
$ cat <<END > /var/www/papi/index.html
<html>
You have reached this PoA !
</html>
END
* In the PoA server (poahost):
$ /etc/init.d/apache restart
* In any browser, access to:
http://poahost/papi/index.html
Your browser will be redirected to the AS for authentication and
then to the protected pages. To authenticate use papitest/papitest
*** Configuration of a GPoA
A GPoA is a special kind of PoA that sits between regular PoA's
and an AS. You can configure the PoA's so that they don't
communicate with the AS, but with the GPoA, and in that case
you don't have to configure the PoA's in the AS, just the
GPoA. It is specially useful because some implementations of
the PAPI protocol (such as phpPoA and the PAPIFilter for
java based resources) are not complete and rely on a
GPoA to work.
The only differences among a GPoA and a regular PoA are:
- You must generate a pair of public and private keys
for the GPoA
- In the Apache configuration of a GPoA you must declare
the GPoA_Priv_Key directive
- The public key of the GPoA must be copyed to a
A regular PoA can use a GPoA just declaring its URL in
the GPoA_URL Apache directive.
$ openssl genrsa -out GPoA_privkey.pem 1024
$ openssl rsa -in GPoA_privkey.pem -pubout -out GPoA_pubkey.pem
$ mv GPoA_pubkey.pem /usr/local/PAPI/PoA/KEYS/_GPoA_pubkey.pem
(the directory must math the Pubkeys_Path Apache directive
and the filename must be exactly that)
$ mkdir /usr/local/PAPI/GPoA
$ mv GPoA_privkey.pem /usr/local/PAPI/GPoA
(you can put it anywhere, you just have to declare its
path in the GPoA_Priv_Key Apache directive inside the
GPoA configuration).
Append these lines to the Apache configuration and restart Apache:
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
<Location /gpoa>
PerlSendHeader On
PerlAccessHandler PAPI::Main
<PAPI_Local>
Service_ID TestGPoA
GPoA_URL wayf:built-in
Req_DB /usr/local/PAPI/PoA/req_TestGPoA
GPoA_Priv_Key /usr/local/PAPI/GPoA/GPoA_privkey.pem
</PAPI_Local>
</Location>
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
Next you must declare the GPoA in the Basic.src file as it where
a regular PoA (Remember to change 'poahost'! ):
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
site::PAPI_test_gpoa::PAPI Test GPoA::http://poahost::/PAPI/cookie_handler.cgi::1800::TestGPoA::/gpoa::index.html::
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
* Using the GPoA
The previously defined PoA can use this GPoA just
declaring:
GPoA_URL http://poahost/gpoa/PAPI/cookie_handler.cgi
instead of 'GPoA_URL wayf:built-in'
For example (create /var/www/papi_gpoa/index.html and change 'poahost'!):
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
<Location /papi_gpoa>
PerlSendHeader On
PerlAccessHandler PAPI::Main
<PAPI_Local>
Service_ID TestPoA_GPoA
GPoA_URL http://poahost/gpoa/PAPI/cookie_handler.cgi
Req_DB /usr/local/PAPI/PoA/req_TestPoa_GPoA
</PAPI_Local>
</Location>
<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>
This way you don't have to declare this PoA in Basic.src
** Finally
* Watch the logs!
- Messages generated by the AS will go to /var/tmp/PAPIAS.log
- Messages generated by the PoA go to the Apache error_log
* If something goes wrong, clear the cookies before starting over!
Mediante el protocolo FTP (File Transfer Protocol) podemos acceder a nuestra cuenta de usuario. Para ello debemos instalarnos un software que permita dicho protocolo. Existen muchos programas en el mercado de transferencia de datos FTP. Existen también programas de dominio público que pueden ser utilizados (FILEZILLA Client por ejemplo).
Para conectarnos a nuestro espacio de usuario debemos indicarle al programa de conexión:
| Servidor FTP: | lucano.uco.es |
| Login ó user: | mi cuenta de correo (ht1gapep por ejemplo) |
| Contraseña o Password: | Contraseña de correo electrónico |
Los contenidos de nuestra página WEB personal hemos de volcarlos en el directorio:
www-docs si se trata de páginas WEB personales.
www si se trata de páginas WEB corporativas.