The IBM Lotus Expeditor restricted workbench is an alternate runtime mode that replaces the operating system shell and prevents a user from accessing system applications and functions without expressed permission from an administrator. The intent of the restricted workbench is to limit a user's access to system operations to only those he needs in order to perform his job. Not only does this allow for increased security, but it also eliminates confusion, thereby increasing the ease with which a user can complete his task. This is an important point for an organization that would like to run Lotus Expeditor as a customer-facing kiosk, as a point-of-sale system, or in a limited task-based environment such as a bank teller's desktop. In these environments, an administrator would want to limit the user's access to only that which he needs. The restricted workbench makes this possible in Lotus Expeditor.

When developing a system that can be installed on Microsoft Windows and Linux and that provides the ability to be a locked-down desktop, you should consider many factors. How are users going to gain access to their existing applications if the entire desktop is locked down? How are users going to perform necessary native functions, such as changing their passwords or simply locking the screen in a restricted environment? What happens if the restricted workbench crashes? You need to consider these and many other questions as you design and develop this Lotus Expeditor feature. Key questions are addressed in this article.

For the purpose of this article, we use the terms restricted mode, restricted workbench, lockdown, and lockdown desktop interchangeably. These are all terms used when discussing the Lotus Expeditor restricted workbench feature.

Prerequisites

Readers should have a strong understanding of the Eclipse plug-in model and of Lotus Expeditor V6.1.

Back to top

The restricted workbench

The restricted workbench provides an environment in which the user is restricted from accessing the operating system and in which the Lotus Expeditor workbench is used as the desktop shell. The workbench behavior, look, and feel are changed after the lockdown feature is installed. The Lotus Expeditor workbench uses the lockdown service to produce a workbench window with the following attributes:

• No title bar
• No sizing borders
• Maximized to fill the screen
• Pinned down in the Z-order such that no other windows can be drawn beneath it
• Cannot be closed
• Cannot be resized
• Cannot be minimized
• File - Exit is removed from the menu bar

Three major components allow Lotus Expeditor to be run in a fully restricted mode:

• An implementation of the ILockdownService interface must be provided. This component is responsible for manipulating the workbench window and ensuring that it cannot be altered by the user.
• The Lotus Expeditor native launcher manages and controls the state of the Lotus Expeditor process. On Windows, the native launcher replaces the system shell.
• Native installation scripts are run as a part of the lockdown installation and are responsible for modifying the operating system configuration. They perform tasks such as updating the registry on Microsoft Windows or altering the Gnome session on Linux.

All three components are discussed in great detail in the following sections.

Back to top

ILockdownService implementation

Lotus Expeditor's WorkbenchWindowAdvisor lays out the workbench window. It is responsible for things such as dictating which widgets are placed on the workbench and where, the presence of a menu bar, and the presence of a toolbar. It has a set of methods that are called at various points in the workbench window's lifecycle.

The Lotus Expeditor default workbench advisor, com.ibm.rcp.platform.personality.DefaultWorkbenchWindowAdvisor, is the advisor object responsible for laying out the default Lotus Expeditor workbench. One of the things that this advisor does is look for the presence of an ILockdownService implementation.

The bundle com.ibm.rcp.lockdown provides a default lockdown service implementation. The restricted workbench feature includes the com.ibm.rcp.lockdown bundle. Therefore, any time the restricted workbench has been installed, an implementation of ILockdownService is present. The DefaultWorkbenchWindowAdvisor locates the lockdown service and calls to it at various lifecycle points during window configuration, such as preWindowOpen() and postWindowOpen(). Calling to the lockdown service at these points allows the advisor to perform the necessary operations on the window before and after it opens. For example, the service pins the window to the bottom of the Z-order, removes the title bar, removes sizing borders, maximizes the window, removes File - Exit from the menu bar, and performs other tasks that lock down this window.

The lockdown service also loads a native DLL and makes JNI calls to perform some of the lockdown function that cannot be implemented in Java code. For example, the native code is actually responsible for pinning the window to the bottom of the Z-order. On Microsoft Windows, it also sets some metrics so that any windows that are minimized while running in this environment are hidden. When in lockdown mode, Lotus Expeditor is the user’s desktop. There is no Microsoft Windows/Gnome task bar on the bottom of the screen. Because of this, there is nowhere for minimized window icons to rest. If they were not handled by Lotus Expeditor they would cover the workbench window. The function that handles the navigation of these open windows is discussed later in more detail.

Another important task that this native code accomplishes is the registration of a low-level keyboard hook that catches and ignores certain keystrokes. In restricted mode, Lotus Expeditor prevents a user from using keyboard shortcuts that allow the user to do things such as open the task manager on Microsoft Windows or simply lock the screen. Lotus Expeditor's keyboard hooks catch and ignore key combinations such as Ctrl + Shift + Esc, Alt + Esc, and Windows Logo Key + L.

After the DefaultWorkbenchWindowAdvisor is finished running, the workbench is displayed and has all the attributes defined here that restrict it.

The bundle com.ibm.rcp.lockdown provides an ILockdownService implementation, LockdownServiceImpl. As stated previously, the DefaultWorkbenchWindowAdvisor uses this service when it is installed and available. Lotus Expeditor allows you to create your own workbench window advisor implementations. Although complete customization of the workbench advisor is beyond the scope of this article, the sample code in listing 1 describes how a developer can use the lockdown service implementation in his custom advisor.

public class RestrictedWorkbenchWindowAdvisor 
						extends WorkbenchWindowAdvisor {
	
private ILockdownService lockdownService;
	
public RestrictedWorkbenchWindowAdvisor(
					WorkbenchWindowConfigurer con
					r){
	
super(configurer);
		
	lockdownService = getRestrictedWorkbenchService();
}
	
public void preWindowOpen(){
	final IWorkbenchWindowConfigurer configurer = 
						getWindowConfigurer();
		
if(lockdownService != null)
		lockdownService.preWindowOpen(configurer);
		
		
	//remaining preWindowOpen activities....
}
	
public void postWindowOpen(){
	final IWorkbenchWindowConfigurer configurer = 
						getWindowConfigurer();
		
	if(lockdownService != null)
		lockdownService.postWindowOpen(configurer);
		
	//remaining postWindowOpen activities....
}
	
/**
  * Returns an instance of the ILockdownService
  * The ILockdownService is available when the Lockdown Feature   
  * is installed.
  */
public static ILockdownService getRestrictedWorkbenchService(){
		
ILockdownService rWorkbenchService = null;
	ServiceReference rWorkbenchServiceRef = 
	Activator.getBundleContext().
		getServiceReference(ILockdownService.class.getName());
		
	if(rWorkbenchServiceRef != null)
		rWorkbenchService = 
			(ILockdownService)Activator.getBundleContext().
									getService(rWorkbenchServiceRef);
		
		return rWorkbenchService;
	}

}

The code sample in listing 1 shows a skeleton of a workbench window advisor. Its purpose is not to demonstrate the development of an entire workbench advisor, but to show how you can use the lockdown service in your own advisor. After the lockdown service has been retrieved, you can make calls to the service's pre- and post-window open methods from the advisor.

The lockdown service provides those things that the user sees from a desktop perspective: a user interface that is locked down. This, however, is only one piece of the restricted workbench puzzle.

Back to top

Installation scripts

The lockdown feature uses Eclipse's install handler capabilities to run native installation scripts as part of feature installation. Depending upon which operating system the installation is running, a different plug-in, containing a different installation script, is installed. On Microsoft Windows, com.ibm.rcp.lockdown.win32 is installed; on Linux, it is com.ibm.rcp.lockdown.gtk. The win32 bundle contains an install.bat file, and the gtk bundle contains a lockdown.sh file.

On Microsoft Windows systems, the install handler executes the scripts, and all operations are performed. This is not the case on Linux. Due to a known issue with Java, the install handler is unable to perform all operations that are part of the installation script. The release note that is packaged with Lotus Expeditor details the steps to run this file.

Due to the operating system dependencies of the restricted workbench, the steps required to restrict a desktop on Microsoft Windows are different from those on Linux. In this article, we focus mainly on the Microsoft Windows installation.

Table 1 outlines all operations performed by the Windows install.bat file.

The Linux installation file, lockdown.sh, from the com.ibm.rcp.lockdown.gtk bundle performs a different set of tasks for securing Linux. It updates the X server configuration files to add DontZap and DontVTSwitch, updates the gdm configuration files to remove unwanted sessions, prevents use of the Ctrl+Alt+Del key sequence, replaces the GNOME default.session file, and disables workspace switching.

The most important thing to understand from table 1 is that the actual operating system shell is replaced when the restricted workbench is installed. Lotus Expeditor does not just pin itself down on top of the standard Windows shell (Explorer.exe); it becomes the operating system shell. If Lotus Expeditor were to crash for some reason – not that it ever would – then the user would see a blank screen, not the OS shell. Because Lotus Expeditor replaces the operating system shell, it takes precautions to ensure that if a platform crash were to occur, the user is not left looking at a blank screen and forced to perform a hard shutdown. To prevent this, Lotus Expeditor contains a watchdog process that runs and monitors the state of the Lotus Expeditor window. This watchdog code is part of the native launcher discussed in the next section.

Back to top

Native launcher

The term native launcher refers to rcplauncher.exe, the executable that launches the Lotus Expeditor client. The restricted workbench relies on the native launcher to monitor the state of the Lotus Expeditor window. It provides a watchdog for the Lotus Expeditor process, continually monitoring its state to ensure it is still active. If the watchdog process detects that the Lotus Expeditor process has terminated, it can check the value of defined variables to determine if it has terminated normally. If it concludes that a crash has occurred, it restarts the desktop automatically, preventing the user from being left to stare at a blank screen.

Privileges

When running on a Microsoft Windows operating system, the rcplauncher.exe file is the file that actually becomes the user’s shell, as discussed previously. The launcher replaces the value Explorer.exe in the Windows registry and is instantiated at system startup. It then has the ability to check the privileges of the user who just logged onto the system. If this user is part of the Administrators group, it changes the value of the shell back to Explorer.exe and Windows starts the traditional desktop, not Lotus Expeditor. If the user is not part of the Administrators group, rcplauncher.exe remains the shell and Lotus Expeditor is launched in restricted mode.

Back to top

Installing the lockdown feature

Lotus Expeditor can be installed in either a single-user environment or a multiuser environment. The features that are installed as part of each of these configurations are defined in an XML installation manifest located in <base_dir>\desktop\install\deploy, where base_dir represents the directory containing the Lotus Expeditor installation files. The restricted desktop can be installed only in a multiuser environment. The file multiuser.xml, located in the directory shown here, must be updated to include an entry for com.ibm.rcp.lockdown.feature for it to install when the Lotus Expeditor installer runs.

After the XML file has been updated to include the com.ibm.rcp.lockdown.feature, the installer displays additional lockdown-specific panels. It is paramount that the user understands what he is about to do because the restricted workbench cannot be uninstalled easily. Installing the restricted workbench is not a decision to be taken lightly.

When installing the restricted workbench feature, choose Multiuser during installation as shown in figure 1. Restricted workbench cannot be installed in a single-user environment.

When the multiuser.xml file has been updated to include the lockdown feature, the panel shown in figure 2 is displayed as part of the installation process. This panel informs the user that lockdown is going to be installed and that many system functions cannot be performed.

Remember, Lotus does not support uninstalling the restricted workbench. Reinstalling the entire system is the documented way to remove the restricted Lotus Expeditor instance.

Figure 3 shows Lotus Expeditor in restricted mode. This window is pinned to the bottom of the Z-order, meaning no other windows can be drawn behind it. There are no sizing borders, there is no window trim, and there is no title bar. This window cannot be closed or minimized.

Back to top

Native function

Once Lotus Expeditor has been installed with the restricted workbench feature, non-admin/non-root users no longer have access to standard operating system functions. A user cannot even log out of the system.

Lotus Expeditor provides a set of native contribution items that can be declaratively added to the workbench so that users can perform common operating system functions. An administrator can add any of these contribution items to any number of places on the workbench by defining them in a plugin.xml file.

The plug-in com.ibm.os.ui provides all the contribution items, actions, and preference pages that Lotus Expeditor includes for performing operating system functions as shown in table 2.

Lotus Expeditor defines the extension point com.ibm.rcp.ui.controlSets that allows contribution items to be declaratively added to the status bar of the workbench. The change password function, the task list, and the clock widget can be contributed to the status bar using the plugin.xml file because a contribution item is provided for each.

Actions and preference pages follow the Eclipse action and preference page models and can be contributed in the standard way. See the Eclipse documentation for more information about how to contribute these items.

The example in listing 2 demonstrates using the controlSets extension point to add an instance of the change password and task list contribution items to the workbench status line.

<extension point="com.ibm.rcp.ui.controlSets">
      <controlSet visible="true" id="example.lockdown.ControlSet">
           <statusLine path="BEGIN_GROUP" id="lockdown.statusline">
                <groupMarker name="additions"/>
           </statusLine>
         
     <control 
statusLinePath="example.lockdown.statusline/additions"
 class="com.ibm.rcp.os.contributions.ChangePasswordContributionItem"
            id="changepassword.control"/>
           <control 
statusLinePath="BEGIN_GROUP"
class="com.ibm.rcp.os.contributions.TaskListContributionIte
 m"
            id="tasklist.control2"/>
      </controlSet>
</extension>

In figure 4, you see there are two new icons on the status line of the workbench. This image shows the task list contribution item selected. The task list allows a user to minimize, maximize, close, or restore any open native window. There is also an icon visible to the far right that, when selected, displays a dialog box allowing the user to change his system password. These contributions were made with the XML entry shown in listing 2.

Back to top

Native applications

Just as the restricted workbench feature prevents users from performing native operating system functions, it also prevents users from launching native applications that they may need. The Start/Application menu on Windows/Linux is not accessible. There is also no way to launch desktop shortcuts.

You can declaratively provide access to native applications through the use of the com.ibm.rcp.ui.launcherSet extension point. The launcherSet extension point can be used by anyone who wants to contribute to the Lotus Expeditor launcher. This is true whether in lockdown mode or not. For the purpose of this article, we are concerned only with the native application portion of this extension point, the nativeProgramLaunchItem. This element can be used to declare a native application and all its configuration information. The native application defined in this extension point appears in the Lotus Expeditor launcher.

Listing 3 is an example of using the launcherSet extension point to contribute two native applications. This declaration contributes Microsoft Paint on Microsoft Windows systems and Gimp on Linux systems.

<extension point="com.ibm.rcp.ui.launcherSet"
     id="com.xyz.test.extension.id">
     <LauncherSet
        id="com.xyz.launcher.native.launcherItems"
        label="Native applications">
        <nativeProgramLaunchItem
            environmentMode="APPEND"
            id="com.xyz.launcher.native.mspaint"
            label="MS Paint"
            platform="win32"
            programCommand="C:\WINDOWS\SYSTEM32\mspaint.exe"
            workingDirectory="c:\temp">
            <environmentVar
                mode="OVERWRITE"
                name="testEnvironmentVar1"
                value="val1"/>
            <environmentVar
                mode="PREPEND"
                name="testEnvironmentVar2"
                value="val2"/>
            <environmentVar
                mode="APPEND"
                name="testEnvironmentVar3"
                value="val3"/>
        </nativeProgramLaunchItem>
        <nativeProgramLaunchItem
            programCommand="/usr/yourname/gimp.exe"
            environmentMode="APPEND"
            id="com.xyz.launcher.native.gimp"
            label="GIMP (Only on Linux)"
            platform="linux"
            workingDirectory="/usr/temp"/>
	</LauncherSet>
</extension>

Because no icon has been provided in the XML, Lotus Expeditor locates the image associated with the defined executable within the operating system. Lotus Expeditor's OS service, com.ibm.rcp.services.ui.os.OSUIService, is responsible for retrieving the executable icon image. An icon may not always be available, and under these circumstances, Lotus Expeditor uses the default icon.

The preceding configuration contributes an action to the Lotus Expeditor launcher for Microsoft Paint with the label of MS Paint on Microsoft Windows as shown in figure 5. When this action is selected, it launches Microsoft Paint. On Linux a "Gimp (Only on Linux)" label with a Gimp icon, if available, is displayed. An extensive number of configuration parameters are available for native applications. Refer to the Lotus Expeditor Information Center for details on all elements of the launcherSet extension point.

Back to top

Window management

We have discussed the need and desire for users to be able to access existing native applications when running Lotus Expeditor in restricted mode. We detailed a couple of Lotus Expeditor’s features that help fulfill this need. Declaratively defining native applications that can be launched from the Lotus Expeditor launcher is one such piece of function. The task list contribution item is also needed to be able to manage native applications. Launching native applications and managing their state with the task list can be done because of the window management component.

Window management refers to the control of native windows. Lotus Expeditor contains a C++ component for Windows and Linux that does things such as retrieve window handles and process identifiers, maintain awareness of all open windows, terminate processes associated with native windows, and retrieve the icon associated with a process or window.

The com.ibm.rcp.os.ui bundle provides a NativeWindow implementation to the com.ibm.rcp.services.ui.os.
NativeWindow service interface. This service implementation is a Java layer to the native code that manages native windows. This implementation is used when launching native applications from the launcher and is also used by the task list contribution item.

The NativeWindow service interface provides methods for manipulating native windows and accessing information about them. The methods available in this interface and the information they provide are detailed in listing 4.

public interface NativeWindow {

/**
 * Returns the platform-specific handle for this native window. It is 
 * not guaranteed that the handle is valid, that is, the window may be
 * closed. To determine if this window is valid use the
 * exists() method.
 */
int getHandle();
	
/**
  * Returns the identifier of the process that this window belongs to
  * or -1 if the process could not be determined.
  */
int getProcessID();
	
/**
  * Returns the text appearing in the title bar of this native window
  * or null, if the window does not exist.
  */
String getTitle();
	
/**
  * Returns the display name of the executable this window belongs to,
  * or null if the window does not exist. This value is
  * typically used as a label for a set of windows that all belong to 
  * the same process.
  */
String getExecutableDisplayName();
/**
  * Returns the window image for this native window or null if
  * the window does not exist.  This is the image that you typically 
  * see in the top left corner of 
  * the window.
  */
Image getIconImage();
	
/**
  * Returns the window image, scaled to the specified height and width, 
  * this native window or null, if the window does not exist.
  * This is the image that you typically see in the top left corner of 
  * the window.
  */
Image getIconImage(int height, int width);
	
/**
  * Returns the image for the executable that launched this window or
  * null if this window does not exist, the executable could
  * not be located, or the executable has no embedded image.
  * This image is typically used to represent a set of windows that all
  * belong to the same process.
  */
Image getExecutableIconImage();
	
/**
  * Returns the image, scaled to the specified height and
  * width, for the executable that launched this window or
  * null if this window does not exist, the executable could
  * not be located, or the executable has no embedded image.
  * This image is typically used to represent a set of windows that all
  * belong to the same process.
  */
Image getExecutableIconImage(int height, int width);
	
/**
  * Returns the absolute path to the executable that launched this
  * window, or null if this window does not exist or the
  * path could not be determined.
  */
String getExecutablePath();
	
/**
  * Returns true if this native window is open. This returns true
  * if the window is open but not visible.
  */
boolean exists();
	
/**
  * Minimizes this native window.
  */
void minimize();
	
/**
  * Maximizes this native window
  */
void maximize();
	
/**
  * Brings this native window to the foreground and gives it focus. If 
  * the window was minimized it is restored to its previous position. 
  */
void restore();
	
/**
  * Closes this native window.
  */
void close();
	
}

In a normal Microsoft Windows or Linux operating environment, a minimized window is represented by an icon and button on the taskbar. You may remember that in the restricted mode the taskbar is eliminated. Therefore, there is no place to put icons associated with minimized windows. Instead, Lotus Expeditor hides minimized windows from the user so as to avoid cluttering the desktop area. A potential problem with this solution is that if a window is out of site, a user may not realize he already has an instance of an application open and may attempt to open another. Although Lotus Expeditor provides the task list item to help navigate the open windows and users still have access to Alt+Tab to change between windows, this may not be enough.

To help curb the issue of multiple application instances being open, Lotus Expeditor provides a track parameter with the com.ibm.rcp.ui.launcherSet extension point. Including the track parameter and setting it to true in your nativeProgramLaunchItem definition cause the first instance of the application to be tracked by the system. By tracking this open window, Lotus Expeditor knows if a user tries to launch another instance of this application and instead brings the existing instance to the foreground.

Listing 5 shows the same snippet of XML shown previously that adds the Microsoft Paint application to the launcher, this time with the track parameter included.

<nativeProgramLaunchItem
            environmentMode="APPEND"
            id="com.xyz.launcher.native.mspaint"
            label="MS Paint"
            platform="win32"
            programCommand="C:\WINDOWS\SYSTEM32\mspaint.exe"
            workingDirectory="c:\temp"
            track="true">
            <environmentVar
                mode="OVERWRITE"
                name="testEnvironmentVar1"
                value="val1"/>
            <environmentVar
                mode="PREPEND"
                name="testEnvironmentVar2"
                value="val2"/>
            <environmentVar
                mode="APPEND"
                name="testEnvironmentVar3"
                value="val3"/>
</nativeProgramLaunchItem>

When Microsoft Paint is first selected in the launcher, it launches a new instance of the application. Each additional selection of this application brings the existing instance to the foreground. The window management capabilities provided by the com.ibm.rcp.os.ui.internal.NativeWindowImpl class along with the com.ibm.rcp.services.os.LaunchContext class make this possible.

The LaunchContext class contains all the configuration information about a declared native application. Whenever a user tries to launch a native application, a LaunchContext object gets created that contains the command, the environment, the working directory, and all other configuration information for that application. The code that is responsible for launching the native application checks if a matching LaunchContext exists; if so, it brings the window associated with that LaunchContext to the foreground. If a matching LaunchContext does not exist, a new instance of the application is launched.

Back to top

Conclusion

The Lotus Expeditor restricted workbench feature can be a valuable tool in a multiuser environment. In this article, we provided all the information needed to fully understand and use this feature. We discussed everything from the intent of lockdown and its possible uses to its setup, installation, and configuration.

Remember that Lotus Expeditor does not support uninstalling the restricted workbench feature because it makes a number of modifications to your system. Even though uninstallation scripts are provided, Lotus Expeditor does not guarantee that your system will revert to its pre-lockdown state when they are run. It is recommended you use a test system if you intend to experiment with the restricted workbench.

Resources

Learn

• Read the developerWorks Lotus article, "Introducing IBM Lotus Expeditor V6.1.1."
  
  
• Read the developerWorks Lotus article, "Getting started with the IBM Lotus Expeditor Toolkit V6.1.1."
  
  
• Read the developerWorks Lotus article, "End-to-end integration with pervasive messaging and IBM Lotus Expeditor micro broker."
  
  
• Read the developerWorks Lotus article, "Building an offline application in IBM Lotus Expeditor."
  
  
• Read the developerWorks Lotus article, "Developing and deploying rich client applications on desktops and mobile devices using IBM Lotus Expeditor V6.1."
  
  
• Read the developerWorks Lotus article, "Migrating Eclipse RCP applications to IBM Lotus Expeditor."
  
  
• Read the developerWorks Lotus article, "Creating collaborative components for IBM Lotus Expeditor Property Broker."
  
  
• Read the developerWorks Lotus article, "Developing an OSGi service as a Web service in IBM Lotus Expeditor."
  
  
• Read the developerWorks Lotus article, "Building and deploying a simple Web Services Resource in IBM Lotus Expeditor."
  
  
• Read the IBM Redbooks publication, Building Composite Applications in Lotus Expeditor V6.1.
  
  
• Read the IBM Redbooks publication, Building Composite Applications.
  
  
• Read the developerWorks Lotus Expeditor page.
  
  
• Refer to the IBM Lotus Expeditor documentation page.
  
  
• Look for additional IBM Lotus Expeditor samples in the developerWorks Lotus Sandbox.
  
  
• Refer to the Eclipse Web site.
  
  

Get products and technologies

• Download a trial version of IBM Lotus Expeditor V6.1.1 Toolkit.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Participate in the developerWorks Lotus team blog.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Prerequisites
• The restricted workbench
• ILockdownService implementation
• Installation scripts
• Native launcher
• Installing the lockdown feature
• Native function
• Native applications
• Window management
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Lotus Expeditor toolkit
• Webcast: A Smart Approach to Core Banking Renovation in a Tough Economic Climate
• Briefing: Smarter collaboration with IBM Lotus solutions
• Buy: Lotus Expeditor toolkit

My developerWorks community

Dig deeper into Lotus on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers