From ff2d326c9f0ef02fd70e3b0c312d6ec5c5af0ca4 Mon Sep 17 00:00:00 2001 From: Ciro Scognamiglio Date: Thu, 31 Jul 2014 12:54:14 +0200 Subject: [PATCH] style changes to the registration pages --- myslice/urls.py | 5 +- portal/static/css/onelab.css | 5 +- .../onelab/onelab_registration_view.html | 36 +- portal/templates/registration_view.html | 565 +++++++++--------- portal/templates/user_register_complete.html | 20 +- 5 files changed, 314 insertions(+), 317 deletions(-) diff --git a/myslice/urls.py b/myslice/urls.py index e8452593..fa72cb9f 100644 --- a/myslice/urls.py +++ b/myslice/urls.py @@ -18,6 +18,8 @@ import portal.homeview import portal.newsview from portal.registrationview import RegistrationView +from portal.contactview import ContactView + from portal.termsview import TermsView home_view=portal.homeview.HomeView.as_view() @@ -103,7 +105,8 @@ urls = [ (r'^management/requests/?$', portal.managementtabrequests.ManagementRequestsView.as_view()), (r'^management/about/?$', portal.managementtababout.ManagementAboutView.as_view()), # - url(r'^register/?$', RegistrationView.as_view(), name='registration'), + url(r'^register/?$', RegistrationView.as_view(), name='registration'), + url(r'^contact/?$', ContactView.as_view(), name='contact'), url(r'^terms/?$', TermsView.as_view(), name='terms'), # url(r'^portal/', include('portal.urls')), diff --git a/portal/static/css/onelab.css b/portal/static/css/onelab.css index 5be1bf37..6fcb05b5 100644 --- a/portal/static/css/onelab.css +++ b/portal/static/css/onelab.css @@ -12,7 +12,10 @@ body { a, a:active, a:focus { outline: 0; text-decoration:none; - color:#201E62; + color:#760073; +} +a:hover { + color:#0D0049; } h1 { diff --git a/portal/templates/onelab/onelab_registration_view.html b/portal/templates/onelab/onelab_registration_view.html index ec3c6e7a..7f1f81af 100644 --- a/portal/templates/onelab/onelab_registration_view.html +++ b/portal/templates/onelab/onelab_registration_view.html @@ -9,32 +9,32 @@
-

Questions? Contact us.

+

Questions? Contact us.

{% if errors %} - +
+
+
    + {% for error in errors %} +
  • {{ error }}
    • + {% endfor %} +
+
+
{% endif %} - - -
-
-
+ + {% csrf_token %}

+ Use the arrow keys to scroll through the list; type part of the name to narrow down the list. We will send an email to + the managers that we have on record for your organization, asking them to validate your sign-up request." required />

Organization not listed? Request its addition now.

@@ -102,8 +102,9 @@
  - If you are a PlanetLab Europe fill in this form using the same email address that you currently use for your PlanetLab Europe account, - your existing credentials will be used to validate your OneLab account. + If you are a PlanetLab Europe user, please fill in this form using the same email address that you + currently use for your PlanetLab Europe account.
+ Your existing credentials will be used to validate your OneLab account. Please be sure to specify a different password for your new OneLab account.
@@ -113,11 +114,10 @@

- +
- {% if errors %} - +
+
+
    + {% for error in errors %} +
  • {{ error }}
    • + {% endfor %} +
+
+
{% endif %}
@@ -56,29 +60,17 @@
-

+ placeholder="Password" required />
+ placeholder="Confirm password" required />
@@ -211,280 +203,275 @@ , with documentation on how to use the tools, pointers to documentation for individual testbeds, and a helpdesk to respond to user questions. -

- Additional support, such as accompaniment through the design and deployment of experiments and the interpretation of their results, is available through - higher levels of service. -

-

- 2.2 Best effort, without guarantees -

-

- OneLab and the owners of the individual OneLab testbeds do their best to provide the services outlined here, with the understanding that Basic level - service offers no guarantees. Users should clearly understand the following limitations. -

-
    -
  • - Reliability: - OneLab does not provide any guarantees with respect to the reliability of the portal, of other tools, or of the individual nodes on platforms. These - may be taken down for maintenance, rebooted, or reinstalled at any time. Reinstallation implies that disks are wiped, meaning that users should not - consider a local disk to be a persistent form of storage. -
    • -
  • - Fitness: - OneLab does not guarantee that the platforms are suitable for the experiments that users intend to conduct. There may be limitations in the - technologies that are offered that prevent certain types of experiments from being carried out. -
    • -
  • - Privacy - : OneLab does not guarantee the privacy of traffic generated on the platforms (e.g., wireless signals, packets). Unless otherwise specified by an - individual platform owner, users should assume that traffic is monitored and logged. Such monitoring may be done intentionally, for example, to allow - platform administrators as well as other users to investigate abuse. -
    • -
-

- Users who seek such guarantees are invited to consider a higher level of service. -

-

- 2.3 Limitedliability -

-

- In no event shall the partners of the OneLab consortium be liable to any user for any consequential, incidental, punitive, or lost profit damages, or for - any damages arising out of loss of use or loss of data, to the extent that such damages arise out of the activities of OneLab consortium partners, or any - breach of the present terms and conditions, even if the consortium partner has been advised of the possibility of such damages. -

-

- Nothing contained in these terms and conditions shall be deemed as creating any rights or liabilities in or for third parties who are not Basic level users - of OneLab. -

-

- 3 Acceptable use policy -

-

- 3.1 Responsibilities of managers and standard users -

-

- OneLab creates and administers accounts for managers and delegates to managers the responsibility for creating and administering accounts for standard - users. Both managers and standard users are required to follow OneLab's acceptable use policy. In addition, managers are fully responsible for the - activities of the standard users whose accounts they create. -

-

- A manager is expected to grant user access only an individual with whom he or she has a working relationship. In general, this means an individual who - works for the same institution as the manager, or, in the case of higher education and research, an individual who is a student at the university where the - manager works. Managers may also grant access to individuals from other institutions, provided that they are collaborating on a common project on OneLab. - If there is a doubt, a manager should refer the question to support@onelab.eu. -

-

- 3.2 Types of use -

-

- OneLab may be used by enterprise, by scientific researchers, and by educators. -

-

- OneLab may be used for pre-commercial research and development. In keeping with OneLab's not-for-profit status, it may not be used to deploy services that - are designed to generate a commercial profit. -

-

- Not-for-profit use of OneLab to deploy services that are designed to generate revenue requires prior approval through a written agreement, and thus may not - be carried out on a Basic level account. Interested users are invited to contact support@onelab.eu. -

-

- OneLab may be used for scientific research. -

-

- OneLab may be used to host lab exercises for university courses. -

-

- Questions about other types of use should be addressed to support@onelab.eu. -

-

- 3.3 Applicable laws and regulations -

-

- OneLab is managed, and the portal is hosted, in France. Information regarding the countries in which individual testbeds are managed and hosted is - available from those testbeds. Users are responsible for being aware of the countries in which their experiments are deployed and for ensuring that their - use of OneLab fully conforms to the laws and regulations of those countries, as well as the laws and regulations of the country in which they themselves - are present when conducting their experiments. -

-

- Above and beyond specific national laws, the activities email spamming, phishing through web services, and all types of Internet fraud are prohibited on - OneLab. -

-

- 3.4 Security and accounting mechanisms -

-

- Users are expected to respect the security and accounting mechanisms put in place by OneLab, its platforms, and federated platforms. For example, access to - PlanetLab Europe is designed to take place through the SSH cryptographically-secured connection protocol, which uses public/private key pair - authentication, and so users should not attempt to bypass this mechanism. As another example, OneLab's notion of a "slice" associates a set of resources - with the group of users who have reserved those resources, and users should not attempt to obscure the identities of participants in a slice. -

-

- Hacking attempts against the OneLab portal and testbeds are not permitted. This includes "red team" (hacker test) experiments. -

-

- 3.5 Sharing of resources -

-

- OneLab is intended for ambitious experiments. Large numbers of resources and extended leases on resources may legitimately be granted in order to carry - these out. At the same time, OneLab and its testbeds are shared environments, and when there is contention for resources, limits must be imposed. -

-

- Each OneLab platform sets its own policies for handling resource contention. As a general rule, users are encouraged to design their experiments to use - resources efficiently. In particular, spinning/busy-waiting techniques for extended periods of time are strongly discouraged. Some resource contention - policies (e.g., PlanetLab Europe's) terminate the jobs that are using the most resources in the case of contention. -

-

- 3.6 Internet-connected platforms -

-

- Some of OneLab's platforms allow experiments to take place on resources that have access to the public internet. These experiments can potentially generate - traffic to, and receive traffic from, any host or router in the internet.[LB1] -

-

- Furthermore, some internet-connected platforms (e.g., PlanetLab Europe) consist of servers that are hosted by a large number of member institutions. -

-

- The accessibility of internet-connected platforms and the distributed hosting model of some of these platforms imply certain responsibilities on the part - of users, as detailed below. -

-

- 3.6.1 General guidance -

-

- A good litmus test when considering whether an experiment is appropriate for such internet-connected platforms is to ask what the network administrator at - one's own organisation would say about the experiment running locally. If the experiment disrupts local activity (e.g., uses more than its share of the - site's internet bandwidth) or triggers complaints from remote network administrators (e.g., performs systematic port scans), then it is not appropriate for - such internet-connected platforms. -

-

- It is the responsibility of the user and the user's manager to ensure that an application that will run on an internet-connected platform is tested and - debugged in a controlled environment, to better understand its behaviour prior to deployment. -

-

- 3.6.2 Standards of network etiquette -

-

- Internet-connected platforms are designed to support experiments that generate unusual traffic, such as network measurements. However, it is expected that - all users adhere to widely accepted standards of network etiquette in an effort to minimise complaints from network administrators. Activities that have - been interpreted as worm and denial-of-service attacks in the past (and should be avoided) include sending SYN packets to port 80 on random machines, - probing random IP addresses, repeatedly pinging routers, overloading bottleneck links with measurement traffic, and probing a single target machine from - many nodes. -

-

- For internet-connected platforms that have a distributed hosting model, each host institution will have its own acceptable use policy. Users should not - knowingly violate such local policies. Conflicts between local policies and OneLab's stated goal of supporting research into wide-area networks should be - brought to the attention of OneLab administrators at support@onelab.eu. -

-

- 3.6.3 Specific network usage rules -

-

- It is not allowed to use one or more nodes of an internet-connected platform to generate a high number of network flows or flood a site with high traffic - to the point of interfering with its normal operation. Use of congestion-controlled flows for large transfers is highly encouraged. -

-

- It is not allowed to perform systematic or random port or address block scans from an internet-connected platform. -

-

- For internet-connected platforms that use a distributed hosting model, it is not allowed to spoof or sniff traffic on a hosted server or on the network the - server belongs to. -

-

- Access to a server on a distributed hosting platform may not be used to gain access to other servers or networked equipment that are not part of the - testbed. -

-

- 3.7 Wireless platforms -

-

- Wireless-connected platforms give users access to nodes that communicate via Wi-Fi and other wireless technologies. They may be capable of detecting - wireless activity in the neighbourhood of those nodes: traffic generated by other users of the platform or by individuals not associated with the platform. - In general, much of the traffic will be encrypted, with certain aspects (such as SSIDs) not encrypted, but it is also possible that there will be fully - unencrypted traffic. They may also be capable of generating wireless activity that reaches equipment outside of the testbed. -

-

- Furthermore, some wireless-connected platforms may have built-in limitations to prevent them from generating signals at a strength that exceeds health and - safety regulations. -

-

- These characteristics of wireless-connected platforms imply certain responsibilities on the part of users, as detailed below. -

-

- 3.7.1 Specific network usage rules -

-

- Experimenters may make no attempt to defeat the encryption of encrypted third-party traffic. Furthermore, experimenters must treat with utmost discretion - any unencrypted traffic. Limited metadata can be recorded for the bona fide purposes of an experiment, but under no case should third party communications - be recorded. -

-

- No attempt may be made to reverse engineer traffic in order to learn the identities of the parties who have generated the traffic. -

-

- Wireless-connected platforms may not be used to gain access to any network equipment that is not part of the testbed itself. -

-

- It is not allowed to perform systematic or random scans of wireless networks that are not part of a wireless-connected platform. Similarly, it is not - allowed to spoof or sniff wireless traffic of the institution that hosts a wireless-connected platform or of other networks in the proximity. -

-

- Care must be taken so that traffic on wireless-connected platforms does not interfere with the normal functioning of network equipment that is not part of - the testbed itself. -

-

- No attempt may be made to defeat the mechanisms that limit signal strength on wireless-connected platforms. -

-

- 3.8 Handling suspected violations -

-

- Suspected violations of the OneLab acceptable use policy should be reported to support@onelab.eu. -

-

- Upon notification or detection of a possible violation, OneLab management will attempt to understand if a violation has in fact occurred. To do so, - management will freely communicate with the users concerned, the operators of the platforms concerned, as well as any third parties that might be involved. - An example of a third party is a network operator who detects what they believe to be unauthorized traffic emanating from a OneLab platform. -

-

- The priority is to resolve any real or apparent violations amicably. However, if OneLab management believes that a violation may have occurred, it can, at - its sole discretion, and without prior notice, apply any of the following measures: -

-
    -
  • - notification of the users of the concerned slice (set of resources); -
    • -
  • - disabling of the concerned slice; -
    • -
  • - disabling an individual user's account; -
    • -
  • - reporting of the user's activity to his/her manager; -
    • -
  • - disabling of the manager's account and all user accounts for which the manager is responsible; -
    • -
  • - disabling of all accounts associated with the user's institution. -
    • -
-

- In the case of suspected illegal activity, OneLab management might need, without prior notice, to notify the relevant authorities. -

-
-
-
-
-
-
+

+ Additional support, such as accompaniment through the design and deployment of experiments and the interpretation of their results, is available through + higher levels of service. +

+

+ 2.2 Best effort, without guarantees +

+

+ OneLab and the owners of the individual OneLab testbeds do their best to provide the services outlined here, with the understanding that Basic level + service offers no guarantees. Users should clearly understand the following limitations. +

+
    +
  • + Reliability: + OneLab does not provide any guarantees with respect to the reliability of the portal, of other tools, or of the individual nodes on platforms. These + may be taken down for maintenance, rebooted, or reinstalled at any time. Reinstallation implies that disks are wiped, meaning that users should not + consider a local disk to be a persistent form of storage. +
    • +
  • + Fitness: + OneLab does not guarantee that the platforms are suitable for the experiments that users intend to conduct. There may be limitations in the + technologies that are offered that prevent certain types of experiments from being carried out. +
    • +
  • + Privacy + : OneLab does not guarantee the privacy of traffic generated on the platforms (e.g., wireless signals, packets). Unless otherwise specified by an + individual platform owner, users should assume that traffic is monitored and logged. Such monitoring may be done intentionally, for example, to allow + platform administrators as well as other users to investigate abuse. +
    • +
+

+ Users who seek such guarantees are invited to consider a higher level of service. +

+

+ 2.3 Limitedliability +

+

+ In no event shall the partners of the OneLab consortium be liable to any user for any consequential, incidental, punitive, or lost profit damages, or for + any damages arising out of loss of use or loss of data, to the extent that such damages arise out of the activities of OneLab consortium partners, or any + breach of the present terms and conditions, even if the consortium partner has been advised of the possibility of such damages. +

+

+ Nothing contained in these terms and conditions shall be deemed as creating any rights or liabilities in or for third parties who are not Basic level users + of OneLab. +

+

+ 3 Acceptable use policy +

+

+ 3.1 Responsibilities of managers and standard users +

+

+ OneLab creates and administers accounts for managers and delegates to managers the responsibility for creating and administering accounts for standard + users. Both managers and standard users are required to follow OneLab's acceptable use policy. In addition, managers are fully responsible for the + activities of the standard users whose accounts they create. +

+

+ A manager is expected to grant user access only an individual with whom he or she has a working relationship. In general, this means an individual who + works for the same institution as the manager, or, in the case of higher education and research, an individual who is a student at the university where the + manager works. Managers may also grant access to individuals from other institutions, provided that they are collaborating on a common project on OneLab. + If there is a doubt, a manager should refer the question to support@onelab.eu. +

+

+ 3.2 Types of use +

+

+ OneLab may be used by enterprise, by scientific researchers, and by educators. +

+

+ OneLab may be used for pre-commercial research and development. In keeping with OneLab's not-for-profit status, it may not be used to deploy services that + are designed to generate a commercial profit. +

+

+ Not-for-profit use of OneLab to deploy services that are designed to generate revenue requires prior approval through a written agreement, and thus may not + be carried out on a Basic level account. Interested users are invited to contact support@onelab.eu. +

+

+ OneLab may be used for scientific research. +

+

+ OneLab may be used to host lab exercises for university courses. +

+

+ Questions about other types of use should be addressed to support@onelab.eu. +

+

+ 3.3 Applicable laws and regulations +

+

+ OneLab is managed, and the portal is hosted, in France. Information regarding the countries in which individual testbeds are managed and hosted is + available from those testbeds. Users are responsible for being aware of the countries in which their experiments are deployed and for ensuring that their + use of OneLab fully conforms to the laws and regulations of those countries, as well as the laws and regulations of the country in which they themselves + are present when conducting their experiments. +

+

+ Above and beyond specific national laws, the activities email spamming, phishing through web services, and all types of Internet fraud are prohibited on + OneLab. +

+

+ 3.4 Security and accounting mechanisms +

+

+ Users are expected to respect the security and accounting mechanisms put in place by OneLab, its platforms, and federated platforms. For example, access to + PlanetLab Europe is designed to take place through the SSH cryptographically-secured connection protocol, which uses public/private key pair + authentication, and so users should not attempt to bypass this mechanism. As another example, OneLab's notion of a "slice" associates a set of resources + with the group of users who have reserved those resources, and users should not attempt to obscure the identities of participants in a slice. +

+

+ Hacking attempts against the OneLab portal and testbeds are not permitted. This includes "red team" (hacker test) experiments. +

+

+ 3.5 Sharing of resources +

+

+ OneLab is intended for ambitious experiments. Large numbers of resources and extended leases on resources may legitimately be granted in order to carry + these out. At the same time, OneLab and its testbeds are shared environments, and when there is contention for resources, limits must be imposed. +

+

+ Each OneLab platform sets its own policies for handling resource contention. As a general rule, users are encouraged to design their experiments to use + resources efficiently. In particular, spinning/busy-waiting techniques for extended periods of time are strongly discouraged. Some resource contention + policies (e.g., PlanetLab Europe's) terminate the jobs that are using the most resources in the case of contention. +

+

+ 3.6 Internet-connected platforms +

+

+ Some of OneLab's platforms allow experiments to take place on resources that have access to the public internet. These experiments can potentially generate + traffic to, and receive traffic from, any host or router in the internet.[LB1] +

+

+ Furthermore, some internet-connected platforms (e.g., PlanetLab Europe) consist of servers that are hosted by a large number of member institutions. +

+

+ The accessibility of internet-connected platforms and the distributed hosting model of some of these platforms imply certain responsibilities on the part + of users, as detailed below. +

+

+ 3.6.1 General guidance +

+

+ A good litmus test when considering whether an experiment is appropriate for such internet-connected platforms is to ask what the network administrator at + one's own organisation would say about the experiment running locally. If the experiment disrupts local activity (e.g., uses more than its share of the + site's internet bandwidth) or triggers complaints from remote network administrators (e.g., performs systematic port scans), then it is not appropriate for + such internet-connected platforms. +

+

+ It is the responsibility of the user and the user's manager to ensure that an application that will run on an internet-connected platform is tested and + debugged in a controlled environment, to better understand its behaviour prior to deployment. +

+

+ 3.6.2 Standards of network etiquette +

+

+ Internet-connected platforms are designed to support experiments that generate unusual traffic, such as network measurements. However, it is expected that + all users adhere to widely accepted standards of network etiquette in an effort to minimise complaints from network administrators. Activities that have + been interpreted as worm and denial-of-service attacks in the past (and should be avoided) include sending SYN packets to port 80 on random machines, + probing random IP addresses, repeatedly pinging routers, overloading bottleneck links with measurement traffic, and probing a single target machine from + many nodes. +

+

+ For internet-connected platforms that have a distributed hosting model, each host institution will have its own acceptable use policy. Users should not + knowingly violate such local policies. Conflicts between local policies and OneLab's stated goal of supporting research into wide-area networks should be + brought to the attention of OneLab administrators at support@onelab.eu. +

+

+ 3.6.3 Specific network usage rules +

+

+ It is not allowed to use one or more nodes of an internet-connected platform to generate a high number of network flows or flood a site with high traffic + to the point of interfering with its normal operation. Use of congestion-controlled flows for large transfers is highly encouraged. +

+

+ It is not allowed to perform systematic or random port or address block scans from an internet-connected platform. +

+

+ For internet-connected platforms that use a distributed hosting model, it is not allowed to spoof or sniff traffic on a hosted server or on the network the + server belongs to. +

+

+ Access to a server on a distributed hosting platform may not be used to gain access to other servers or networked equipment that are not part of the + testbed. +

+

+ 3.7 Wireless platforms +

+

+ Wireless-connected platforms give users access to nodes that communicate via Wi-Fi and other wireless technologies. They may be capable of detecting + wireless activity in the neighbourhood of those nodes: traffic generated by other users of the platform or by individuals not associated with the platform. + In general, much of the traffic will be encrypted, with certain aspects (such as SSIDs) not encrypted, but it is also possible that there will be fully + unencrypted traffic. They may also be capable of generating wireless activity that reaches equipment outside of the testbed. +

+

+ Furthermore, some wireless-connected platforms may have built-in limitations to prevent them from generating signals at a strength that exceeds health and + safety regulations. +

+

+ These characteristics of wireless-connected platforms imply certain responsibilities on the part of users, as detailed below. +

+

+ 3.7.1 Specific network usage rules +

+

+ Experimenters may make no attempt to defeat the encryption of encrypted third-party traffic. Furthermore, experimenters must treat with utmost discretion + any unencrypted traffic. Limited metadata can be recorded for the bona fide purposes of an experiment, but under no case should third party communications + be recorded. +

+

+ No attempt may be made to reverse engineer traffic in order to learn the identities of the parties who have generated the traffic. +

+

+ Wireless-connected platforms may not be used to gain access to any network equipment that is not part of the testbed itself. +

+

+ It is not allowed to perform systematic or random scans of wireless networks that are not part of a wireless-connected platform. Similarly, it is not + allowed to spoof or sniff wireless traffic of the institution that hosts a wireless-connected platform or of other networks in the proximity. +

+

+ Care must be taken so that traffic on wireless-connected platforms does not interfere with the normal functioning of network equipment that is not part of + the testbed itself. +

+

+ No attempt may be made to defeat the mechanisms that limit signal strength on wireless-connected platforms. +

+

+ 3.8 Handling suspected violations +

+

+ Suspected violations of the OneLab acceptable use policy should be reported to support@onelab.eu. +

+

+ Upon notification or detection of a possible violation, OneLab management will attempt to understand if a violation has in fact occurred. To do so, + management will freely communicate with the users concerned, the operators of the platforms concerned, as well as any third parties that might be involved. + An example of a third party is a network operator who detects what they believe to be unauthorized traffic emanating from a OneLab platform. +

+

+ The priority is to resolve any real or apparent violations amicably. However, if OneLab management believes that a violation may have occurred, it can, at + its sole discretion, and without prior notice, apply any of the following measures: +

+
    +
  • + notification of the users of the concerned slice (set of resources); +
    • +
  • + disabling of the concerned slice; +
    • +
  • + disabling an individual user's account; +
    • +
  • + reporting of the user's activity to his/her manager; +
    • +
  • + disabling of the manager's account and all user accounts for which the manager is responsible; +
    • +
  • + disabling of all accounts associated with the user's institution. +
    • +
+

+ In the case of suspected illegal activity, OneLab management might need, without prior notice, to notify the relevant authorities. +

+
- +