90 Guest User
What is a Guest User?
Guest User is the meta-user whose layout is presented as the (unmodifiable) layout of the unauthenticated user. A portal maintainer "logs in as guest" to adjust the "guest layout". Changes to the guest user's layout are reflected in the unauthenticated view on the portal after the portal is next restarted, since the guest layout is aggressively cached.
You can have (in theory anyway) more than one Guest User and different unauthenticated layouts among which your portal switches (say based on the IP address from which the request originates – an on campus unauthenticated view and an off campus unauthenticated view – but this is an advanced usage and probably doesn't work perfectly since probably no one is actually exercising it.
How do I log in as the Guest User?
If you're using an external authentication mechanism, such as LDAP, then maybe you have an external user named guest with a pasword. But you probably don't. So you need uPortal to provide a local mechanism to authenticate the guest user.
Out of the box, the guest user does not have a local password. There are two basic ways to configure the guest user with a password. One way is with an Ant task (accomplishing this task from the command line.) Another way is via an administrative channel.
Configuring a guest user password via the administrative channel is a two step process. First, create a user with username "guest". Second, set the password for that user.
Navigate to the Password Management channel, which is included in the latest uPortal 2.5.x release. You'll need to log in as admin to have access to it (unless you've modified its permissions in Channel Manager – be careful if you do not to give unintended users access to password management!). It is included in the Admin Tools tab of the default ALM layout. You'll need to add it to the layout if you're not using ALM.
Once you get there, you'll see a form providing the user account information for the user as whom you're logged in (admin). Click "Add New User" to begin creating the Guest user. (The user already exists to the extent that it has a layout, but it doesn't have local account information and therefore no uPortal-local password.)
Complete the form with information for the new Guest User. The important bit is that the "User name" is exactly "guest". Click "Save" to save the new user information.
Once you've clicked "Save" from the user adding screen, you'll get a screen showing information about this Guest User. This confirms that Guest is still the "selected user" in the Password Manager. (Yes, the Password Manager could have much better user factors. Volunteers to work on this?)
Now that you've got a Guest User existing in the local database, you can "Set Password" for this user. Click "Set Password".
Give the Guest User a password. Here I've chosen "guest". You should pick something much harder to guess in a production environment, since this will be the user account and password whereby someone can edit your unauthenticated layout.
Once you've typed the new password into both boxes, click "Set Password".
You've now got a Guest User with a uPortal-local password. To try out logging in as guest, you'll need to log out of your portal to get out of the admin account.
Now that you've logged out, you can log back in "as guest" using the new password you've set.
uPortal will confirm that you've successfully logged in as guest (at least in the default theme and settings). You can now edit this user's layout to reconfigure the unauthenticated layout for your uPortal. Remember that while these changes will be reflected immediately for "the guest user" (when you're "logged in as guest"), they will only take effect for the unauthenticated view on your portal when you next restart your uPortal.
How does DLM change how I might think about the Guest User?
While you can log in as the Guest User and manage the layout of the unauthenticated view of your portal by changing the guest user's layout under DLM, you don't need to do this. Instead, you can compose the guest layout of DLM Managed Fragments via dlm.xml and DLM Layout Owners whose layouts make up the content of Managed Fragments. Advantages of going this route include the ability to use the same managed fragments for both the unauthenticated view and authenticated views (you might want to be share a Main tab across both contexts, for instance) and the ability to delegate management over pieces of the Guest Layout.
It doesn't make a whole lot of difference which route you go and you can use both guest user layout and managed fragments to compose your unauthenticated user experience, but that's needless complexity.