GitLab

their experiments, we fall back to naming it for them.

We now ask the portal for a the user's project membership list, and if the
user is not a member of any (unexpired) projects, we do not allow them to
create experiments (or much of anything else) in the Cloud Portal. I did
this by setting the local holding project trust to "user" and setting the
webonly bit in the users table. The user can use the picker to see public
profiles, but the create button tells them no dice, go join a project at
the GPO portal.

We make the project check each time the user logs in via the trusted
signer.

parameterized profile. Note that we don't use this path much, but
we might in the future.

* Various UI tweaks for profile versioning.

* Roll out profile versioning for all users.

* Disable/Hide publishing for now.

* Move profile/version URLs into a modal that is invoked by a new Share
  button, that explains things a little better.

* Unify profile permissions between APT/Cloudlab. Users now see just two
  choices; project or anyone, where anyone includes guest users in the APT
  interface, for now.

* Get rid of "List on the front page" checkbox, all public profiles will be
  listed, but red-dot can still set that bit.

* Return the publicURL dynamically in the status blob, and set/show the
  sliver info button as soon as we get it.

* Console password support; if the aggregate returns the console password,
  add an item to the context menu to show it.

* Other stuff.

box about keys.

1) Implement the latest dataset read/write access settings from frontend to
   backend. Also updates for simultaneous read-only usage.

2) New configure options: PROTOGENI_LOCALUSER and PROTOGENI_GENIWEBLOGIN.

   The first changes the way that projects and users are treated at the
   CM. When set, we create real accounts (marked as nonlocal) for users and
   also create real projects (also marked as nonlocal). Users are added to
   those projects according to their credentials. The underlying experiment
   is thus owned by the user and in the project, although all the work is
   still done by the geniuser pseudo user. The advantage of this approach
   is that we can use standard emulab access checks to control access to
   objects like datasets. Maybe images too at some point.

   NOTE: Users are not removed from projects once they are added; we are
   going to need to deal with this, perhaps by adding an expiration stamp
   to the groups_membership tables, and using the credential expiration to
   mark it.

   The second new configure option turns on the web login via the geni
   trusted signer. So, if I create a sliver on a backend cluster when both
   options are set, I can use the trusted signer to log into my newly
   created account on the cluster, and see it (via the emulab classic web
   interface).

   All this is in flux, might end up being a bogus approach in the end.

dangerously close to a full rewrite.

UI to not use modals.

the instructions.

logins like unapproved user, expired password, etc. Needs some work
though, since the auth code is not branded, and so the links are wrong.
Will do that next, but want to get this in right away.

users yet.

all users. Cloudlab added to the list, but not exposed except to
admins and studly users.

certificate or an expired certificate, create a new one automatically.
We will reuse the private of an existing but expired certificate.

box, but as a collapsible. Warn user if they do not have a key (provided on
signup page) that they are restricted to browser shell. Whenever user
provides a key, replace in the database (if its changed). This keeps the
user out of the Emulab interface to edit their ssh keys. Might have to
revisit this if APT/Cloud users need/want more then the one key.

we know (suspect) the user has an account, so redirect to the login
page. There is a new Continue as Guest button on the login page in
case that is what the user really wants to do.

This will cause an initial encrypted SSL certificate to be created when
the account is approved.

going to ignore the listed flag, and show users (guest or logged in) those
profiles they are allowed to instantiate.