text:
Related Reading
WebLogic: The Definitive Guide
Editor's note: In part one in a two-part series of excerpts from Chapter 17 of WebLogic: The Definitive Guide, authors Avinash Chugh and Jon Mountjoy examine WebLogic's various security mechanisms, beginning with a look at the Java Security Manager and how WebLogic filters connection requests. They also cover WebLogic's authentication and authorization framework and how it supports the standard J2EE security services.
WebLogic provides a comprehensive suite of security services that can be used to protect all aspects of a domain and its deployments. These security services affect all aspects of your domain: from the lowest level provided by the Java Security Manager, to connection-level security, to application-level security in which you can protect your administered and deployed objects (such as EJBs, web services, and JDBC pools), and finally to domain-level security in which you can establish trust between two domains. These security services target three distinct sets of users: application developers who can use the services to secure their applications; administrators who need to configure security for the system and deployments; and security vendors or customers who can change and extend the facilities provided by WebLogic.
Let's begin at the JVMlevel. Here, the Java Security Manager uses a security policy file to restrict access to specific runtime operations. This ensures that programs running on the JVM, including WebLogic Server itself, can access protected resources in permitted ways only. For instance, you can configure the Java Security Manager so that all Java threads have write-access only to specific directories in the filesystem. WebLogic enhances the Security Manager by allowing you to define additional security policies for resource adapters and EJBs, thereby ensuring that these components have access to defined resources only. There are also other global, higher-level security permissions that apply to these resources and application code.
WebLogic can filter connection requests from clients. A connection filter defines rules that determine what basis the server accepts or denies client connections. These rules are based on several parameters: typically, the client's IP address and port; the protocol used to establish the connection; and the server's listen address and port. You can assign multiple connection filters to a server, or perhaps even write your own connection filter class that implements custom filtering logic. Using connection filters, you can easily ensure that the server accepts only T3 connections from within your intranet, for example. SSL security is another mechanism available at the socket level, which we encountered in Chapter 16. SSL protects network communication provided through its support for data integrity, confidentiality, and authentication.
WebLogic provides partial support for standard JAAS. The JAAS framework is a standard extension to J2SE v1.3 and is now part of the J2SE v1.4 platform. Authentication enables the server to verify the identity of the user who is running the Java code, whether it is an applet, servlet, EJB, or application. Authorization is the server's ability to enforce access control based on the user's identity, security privileges, and policies. WebLogic allows Java clients to use JAAS authentication, and login modules are implemented using JAAS. If you need to use JAAS authorization, you will have to code your own schema above WebLogic's infrastructure.
WebLogic's security infrastructure is founded on a set of modular, extensible security service provider interfaces (SSPIs). This architecture allows you to plug in new security providers, swap out old ones, and run WebLogic's default providers alongside your own. Your WebLogic distribution is equipped with a set of security providers that provide the default implementations for the SSPIs. WebLogic's security providers implement the underlying security framework for your J2EE applications. That is, the standard J2EE-defined security mechanisms are implemented (and extended) through the SSPIs. Often, WebLogic's security providers will refine the existing security constraints. For instance, the standard ejb-jar.xml deployment descriptor allows you to restrict access to an EJB method to authenticated users in a specific role. WebLogic allows you to refine this constraint by ensuring that the user has access only during certain times of the day. In fact, the SSPIs are an open architecture, and you can easily plug in a third-party security provider from a security vendor. Alternatively, you can build new security services by implementing your own security providers.
WebLogic's default security providers are quite versatile. A security realm is a logical grouping of users, groups, roles, and security policies, along with the complete set of security providers. Security policies assigned to server resources can be used to determine who is authorized to access the resource. WebLogic lets you protect a whole range of resources: individual EJB methods, a web application, a collection of web pages, connection pools, data sources, or any administered object. You even can protect a branch within the JNDI tree, thereby preventing unauthorized clients from looking up objects in the JNDI tree. All this security data is stored in an embedded LDAP server. WebLogic also can be configured to use an external LDAP repository, such as Open LDAP, Active Directory, or Novell NDS. These external repositories can be used for authentication only, not authorization.
Finally, WebLogic allows you to set up a trust mechanism between two domains. This ensures that authenticated users from one domain can then access resources in another domain.
This chapter examines all of these security mechanisms. Although they are all quite different from each other, they complement each other quite well. We begin with a look at the Java Security Manager and how WebLogic is able to filter connection requests. We then examine WebLogic's authentication and authorization framework and learn how it supports the standard J2EE security services. We also coverthe various security providers available within a security realm and their default implementations. Finally, we end with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion providers.
At the JVMlevel, WebLogic can use the standard Java Security Manager to prevent untrusted code from performing unwanted actions. Using a security policy file, you can configure the JVMso that all threads running on the JVMhave restricted access to sensitive runtime operations. The security policy file encapsulates a set of permissions that are granted to (or revoked from) all classes loaded within the current instance of the JVM. You can define a whole range of security permissions to control access to particular resources—e.g., "write" access to certain folders on the filesystem, "connect" access to a particular host and range of ports, "read" access to environment variables, "get" access to the current class loader, and more. Refer to your JDK documentation for more information on the Security Manager and security policy files.
Java's Security Manager ensures that any code running within WebLogic accesses these critical resources only in the permitted ways. This low level of access control may be useful for third-party untrusted code. The Java Security Manager also can interact with J2EE deployment settings. For instance, you can use the standard ra.xml deployment descriptor to define security permissions that apply to the resource adapter. WebLogic also provides similar access control for web applications and EJBs.
Note that WebLogic itself requires a policy file to be in place before it can run. The
startWebLogic scripts load the policy file located at WL_HOME/server/lib/weblogic.
policy by default.
In order to use the Java Security Manager, you need to supply two options from the command line when starting WebLogic Server:
–Djava.security.manager option to ensure that the default
security manager is installed, and that the JVM is subjected to policy checks.
–Djava.security.policy option to specify the location of a
security policy file.
By default, the JVMuses security policies defined in the java.security and java.policy files located under the JAVA_HOME/jre/lib/security folder. Here is the syntax for starting WebLogic Server using a custom security policy file:
java –Djava.security.manager –Djava.security.policy==c:\oreilly.policy
... weblogic.Server
The default startup scripts created by WebLogic refer to the sample security policy
file located at WL_HOME/server/lib/weblogic.policy. Notice how we've used the
(double equal sign) when specifying the
java.security.policy argument. This persuades
the Security Manager to use c:\oreilly.policy as its only source of policies. If we
had used a single equal sign instead, the policy file would be used in conjunction
with default security policy files provided by your JDK installation.
Usually the JVMwill use the security policy file to enforce access control over any code running within WebLogic. The only deviation from this rule is when WebLogic Server starts up. When a server boots up, WebLogic partially disables the Java Security Manager and replaces it with a variation that disables the checkRead( ) method. While this approach improves the performance of the startup sequence, it also reduces the security of the JVMduring startup. In addition, it means that the startup classes for WebLogic will run using this modified security manager. You will need to ensure that these classes cause no security breaches.
Note: Because the policy file determines access privileges for all classes running within WebLogic's JVM, we recommend that only the Administrator has read and write access to the security policy file. No other users should be allowed to access the policy file.
WebLogic allows you to define security policies for EJBs, resource adapters, and web applications in the weblogic.policy file. Table 17-1 lists the codebases under which the default permissions for these component types may be defined.
Table 17-1. Default codebases for access permissions that apply to J2EE components
|Application type
|Resource adapters
You can use these codebases to grant special privileges to particular J2EE component types. Note that any security policies defined under these codebases apply to all EJBs, resource adapters, and web applications deployed to that particular server instance.
Let's look at specifying permissions for EJBs. The security-permission element in the weblogic-ejb-jar.xml descriptor specifies security privileges that apply to all EJBs packaged in the EJB JAR. The following example grants read and write access to a temporary directory on the server's filesystem for the EJBs:
<!-- webLogic enterprise bean statements go here -->
<!-- the optional security role assignments go here -->
grant permission to special folder
grant {
permission java.io.FilePermission
"f:${/}tmp${/}-", "read,write";
Notice how the security-permission-spec element defines a grant permission using the same syntax for security policy files. The only restriction to this syntax is that you cannot use the codebase or signedBy clauses.
BEA provides a Recording Security Manager that can be used to trace any permission problems caused by the Java Security Manager. When installed, the tool detects and records all access control exceptions that occur at runtime. In this way, you can easily pinpoint problems in your access control policy and later reconfigure the security policy to remove these errors. The tool is not distributed with WebLogic Server. However, it can be downloaded from BEA's dev2dev web site (http://www.dev2dev.bea.com).
At the connection level, WebLogic provides two security features: filtering and SSL. Chapter 16 provides a detailed look at SSL. Let's take a look at connection filtering here. A connection filter allows the server to reject unwanted connections based on some criteria. For example, a connection filter would allow you to configure WebLogic to permit T3 or IIOP connections only from within your intranet, and reject any T3 or IIOP connection request from outside the intranet. So, connection filtering provides network-level access control.
WebLogic comes equipped with a default connection filter that examines one or
more connection filter rules defined in the Administration Console. Alternatively,
you can create your own custom connection filter that evaluates the basis that
incoming connections are accepted by the server. A custom connection filter is a Java
class that implements WebLogic's
ConnectionFilter interface. The interface is dead
simple—the class must implement the
accept() method, which simply throws a
to indicate that an incoming connection request should not be allowed through. Here is an example of a connection filter that refuses T3 connections from hosts unless their IP address matches 10.*.*.*:
import weblogic.security.net.*;
public class MyConnectionFilter implements ConnectionFilter {
public void accept(ConnectionEvent evt) throws FilterException {
if ( evt.getProtocol( ).equals("t3") ) {
byte [] addr = evt.getRemoteAddress( ).getAddress( );
if ( !(addr[0]==10))
throw new FilterException( );
This filter simply throws a
FilterException whenever the filter criteria have been violated.
If the method completes without throwing any exceptions, the connection is
allowed through. The method receives a single parameter, a
ConnectionEvent object,
that encapsulates vital information about the connection request. Typically, you will
use this information to implement the acceptance criteria for the filter. The
ConnectionEvent class provides various methods to access this information:
Retrieves a string value that represents the protocol used to establish the connection.
Retrieves a
java.net.InetAddress object that represents the client's address.
Returns the client's port number used to establish the connection.
Retrieves a
java.net.InetAddress object that represents the server's listen
Obtains the server's port number to which the connection is being made.
Once you have compiled the filter class, you need to install it. First, you need to ensure the class can be located from the server's classpath. Then, using the Administration Console, expand the topmost node indicating your domain and choose the View Domain-Wide Security Settings option. The Configuration/Filter tab contains the settings for connection filters. WebLogic 7.0 users should select the Security/Filter tab after expanding the domain node from the left pane.
Enter the name of your connection filter class in the Connection Filter setting. You
will also notice the Connection Filter Rules setting. Use this option if your filter class
also implements the optional
ConnectionFilterRulesListener interface. In this case,
the connection filter will be able to receive and process filter rules defined in the
Administration Console.
WebLogic comes preconfigured with a useful connection filter that can process a number of filter rules defined using the Administration Console in the Connection Filter Rules setting. The connection filter attempts to match an incoming connection against all the rules, beginning from the first rule in the list. If a matching rule is found, the connection is allowed (or disallowed) depending on the rule's action. If no matching rule is found, the incoming connection is permitted.
You can specify any number of rules; each rule should be on a single line. The syntax for a connection filter rule is shown here:
target localAddress localPort action protocolList
Here are the definitions for the parameters of a connection filter rule:
localAddress parameter refers to the server's host address to which the client
connects. If you specify an asterisk (*), this matches all local IP addresses.
localPort parameter indicates the server port to which the client connects.
If you specify an asterisk (*), this matches all available ports.
allow or
protocolList parameter to define a space-separated list of protocol
names that should be matched. The protocol names can be:
http, https, t3, t3s,
giop, giops, dcom, or
ftp. If no protocols are listed, the rule checks for all protocols.
Versions of WebLogic 7.0 and WebLogic 8.1 also permit the
ldap protocol
to be specified.
You also can include a # character anywhere on the line. Any text after this character until the end of the line is treated as a comment.
A filter rule can define the target parameter in two forms:
For fast rules, you can specify either the client's hostname or IP address. The IP address can be followed by an optional netmask, the two being separated by a / character. If you supply a hostname that resolves to a list of IP addresses, the server automatically generates multiple versions of the same rule for each IP address when it boots up. These rules are called "fast" because the server eventually has a list of rules that use static IP addresses; therefore, no connect-time DNS lookups are required once the server is up and running. All hostnames are resolved to their IP addresses when the server boots and goes through all the filter rules. Here are a few examples of fast rules:
www.oreilly.com 127.0.0.1 7001 allow t3 # allow t3 requests from www.oreilly.com
10.0.20.30/255.255.0.0 127.0.0.1 7001 allow t3 t3s http https
Notice how the second filter rule uses a netmask.
For slow rules, the value for the target parameter is a domain name beginning with an asterisk (*). An asterisk may be used only at the head of the domain name. Here is an example of a slow rule:
*.oreilly.com 127.0.0.1 7001 allow t3
This rule allows incoming T3 connections on port 7001 from any client that runs on a host within the oreilly.com domain. It's called a "slow" rule because it requires a connect-time DNS lookup in order to execute the match, so it is literally slower than the fast rules.
The following rule is very handy for denying all access to your server:
0.0.0.0/0 deny # refuse the connection request
You can define this rule at the end of the list of filter rules, and thereby deny access to all connections that fail to match any of the previous rules in the list. In this way, you can ensure that an incoming connection request is allowed only if it matches one of the preceding filter rules.
Let's now turn our attention to WebLogic's infrastructure for application-level security. WebLogic defines a standard set of SSPIs that provide high-level security services. WebLogic also supplies a default set of security providers that implement these SSPIs. These default security providers support and enhance the standard J2EE rolebased security framework. In fact, they also allow you to programmatically control its behavior. There are two important characteristics of this security framework:
The SSPIs are split into discrete modules so that each security provider can deal with different but specific aspects of WebLogic's security (e.g., authentication, authorization, auditing, and more).
Because these security providers live behind a layer of SSPIs, WebLogic makes it easier to replace or enhance the default implementation with your own or a third-party implementation.
The SSPIs hide the actual implementation of the security providers, thereby enabling you to plug in and play your own modules and modify selected aspects of the security. For instance, the default Authentication Provider can be replaced with one that supports some form of biometric recognition, or the Auditing Provider can be replaced with one that notifies interested parties after a user has made a certain number of failed attempts to log in.
A security realm is a logical grouping of users, groups, roles, and security policies,
along with a complete set of security providers. By default, WebLogic Server comes
equipped with two such realms: the legacy compatibility realm that provides support
for WebLogic 6.x–type security configurations, and the new default realm. The default realm which is often referred to by its default name
myrealm is WebLogic's
standard implementation of the security providers. Although you can configure multiple
realms for a domain, one realm can be active only; this active realm controls all
aspects of the domain's security.
You can determine which realm your domain is set up to use by selecting the domain from the left frame of the Administration Console and then choosing the View Domain-Wide Security Settings option. The Configuration/General tab displays a Default Realm field that indicates the security realm currently being used by your domain. The Administration Console lets you configure virtually all aspects of the security realm. You can view and modify the realm's configuration by selecting the realm from under the Security/Realms node in the left pane of the Administration Console. Here, you will find subnodes for all the security providers within the realm, together with access to the realm's users, groups, and roles.
To understand how WebLogic's default security realm works, you need to understand the authentication and authorization structure that WebLogic imposes on its resources and how it integrates with the standard J2EE role-based security. The remainder of this section is dedicated to exploring these concepts. The following section examines the security providers in more detail.
WebLogic's authentication and authorization providers, part of the default implementation of the SSPIs, rely on the important concepts shown in the following list.
You can use WebLogic to configure these entities and thereby protect any resource within a domain, right from the call to an EJB method all the way through to a particular operation from the Administration Console. This framework prohibits unauthorized access both from within (e.g., a servlet invoking an EJB method) and from without (e.g., a Java client attempting to use a JDBC data source).
To place these concepts in context, let's refer back to the "Security Configuration" section
in Chapter 2, where we examined how to protect the web resources in the /admin directory of a web application. In the standard web.xml deployment descriptor, we defined a security constraint that granted access to a security role named
<!-- web.xml entry: -->
<web-resource-name>Admin Resources</web-resource-name>
<description>security constraints for admin stuff</description>
Of course, this setup relies on a security role that we also defined in the descriptor file:
<!-- web.xml entry: -->
Up until this point, we have utilized the standard J2EE security features found in the
deployment descriptors. Now we have to assign the virtual security role defined in
web.xml file to an actual physical entity in WebLogic Server. This is achieved by
associating the role name to a number of principals already configured in WebLogic
Server. The
weblogic.xml descriptor file for the web application holds this mapping:
<!-- weblogic.xml fragment -->
This XML fragment correlates the webadmin role defined and used within the web
application with the actual WebLogic users
jmountjoy and
achugh. In this way, we are
able to prohibit users who are not in the
webadmin role from accessing web content
under the /admin folder. Let's now look at just how this setup protects the web
resources in the web application.
A protected resource restricts access to only a subset of users. Any user that satisfies the access constraints laid down on the protected resource is then authorized to access the resource. WebLogic lets you protect a variety of resources: web applications, URLs (as in the earlier example), individual EJB methods, web services, connection pools, and even branches of the JNDI tree. For instance, you could ensure that only certain users are allowed to access a connection pool or invoke a method on a protected EJB. In the case of our sample web application, the set of URLs matching the pattern /admin/* represents a protected resource. This means that you can easily set up a secure environment in which applications are forced to obey the security constraints that you've laid out. WebLogic also makes it easy to adapt the configuration according to your needs with minimal code changes. In the case of our sample web application, the security constraints are defined declaratively in the deployment descriptors. Thus, you can adjust the security settings with no code changes.
The access control mechanism relies on the notion of an authenticated user. The user represents an authenticated entity—it could be a person (as in this case) or an external, client program. A user may authenticate itself in different ways. Over the Web, a user may be required to fill in a login form. A Java client application, on the other hand, may rely on JAAS authentication to establish trust with WebLogic Server. In our example, the user is determined from the username and password (login credentials) supplied over the Web. In general, a user has a number of principals (identities) associated with it as a result of an authentication. For instance, the principals associated with the system user after successful authentication include the system user itself and the group to which it belongs—i.e., the Administrators group. Some users may not authenticate at all, in which case they will remain anonymous.
When the domain holds an overwhelming number of WebLogic users, it becomes cumbersome to manage the security needs of each individual user. For this reason, WebLogic lets you configure static collections of users, called groups. From a security point of view, if a role or policy statement is applied to a group, the role or policy is assigned to all members of the group. From an administration point of view, it is easier to manage a handful of groups rather than (say) several hundred users. Remember, a group is a static collection of users. An administrator explicitly defines the members of a group at configuration time. As we saw earlier, a group can also act as a security principal. So, for instance, our weblogic.xml descriptor file could easily map the security role to the name of an existing group:
<!-- weblogic.xml fragment -->
In this case, access to the web content would be restricted only to all users within
A security role represents a dynamic collection of users whose membership is evaluated
at runtime based on the subject's principals and other membership criteria.
Whether a user is in a role depends on whether the user satisfies the membership conditions
of the role at runtime. You can specify a number of membership conditions
for the role. These include a logical mix of usernames, group names, and times of
access during the day. For instance, you may define the membership condition for
DayShopper role as being "any user who belongs to the
Shopper group and the
time of access is between 8:00 a.m. and 5:00 p.m.". You may assign a number of
roles to a resource in order to help specify the authorization conditions of the
resource. Note that the roles themselves do not guarantee access control, they just
facilitate in the definition of a policy statement that ultimately protects access to the
target resource. In terms of the earlier example, we created a role called
The membership conditions for the role are simple: the client has to be authenticated
as either
jmountjoy or achugh before the web application considers it in the
webadmin role.
You can protect a WebLogic resource by defining a policy statement for it. A security
policy is a statement about access—it determines which users will have access to
the resource. Just as you can with roles, you can define a policy in terms of a logical
combination of a number of conditions: usernames, group names, the time of access
during the day, and role names. For instance, you could assign the following policy
to a JDBC pool: "the caller must belong to the
DayShopper role or the
group." This means that only authenticated users who belong to the
group or pass the membership criteria of the
DayShopper role may access the pool. If
any user fails these access control checks defined for the JDBC pool, WebLogic will
raise an authorization exception.
Now let's revisit the earlier security constraints on our web application in terms of
these concepts. The weblogic.xml descriptor file defines a
webadmin role. At deploy
time, WebLogic reads this descriptor file and creates a
webadmin role within its internal
security configuration. This internal security role is configured to ensure that
only the users
achugh and
jmountjoy can qualify for membership to this role. Thus,
the J2EE role gets mapped to a WebLogic role, whereas the role-to-principal(s)
assignment defines the membership criteria for the internal role.
In addition, WebLogic creates and assigns a policy statement to the web application
that protects all web resources that match the URL pattern /admin/*. The policy
statement will grant access to any caller satisfying the following condition: "the caller
is in the
webadmin role." Through this policy statement, WebLogic can ensure that
any user who isn't a member of the
webadmin role is unable to access the web content
under the /admin folder. Thus, WebLogic relies on a behind-the-scenes policy statement
to enforce the security constraints defined by the deployment descriptors.
Later, we see how you can explicitly create your own policy statements.
To list the users that belong to a realm, select the realm from the Administration Console and choose the Users node. You then can use the righthand frame to view all the users or filter the list. The System user account also will be part of the list— this is the Administration user account that was defined when you used the Configuration Wizard to create the domain. Select the "Configure a new User" option to create a new user. For each user, you need to specify a name, a short description, and a password. Note that all usernames within a realm must be unique. The default provider uses case-insensitive usernames. The user may belong to one or more groups.
To list and edit all the groups that belong to a security realm, select the realm from the Administration Console and then choose the Groups node. You can also create a new group here. The Membership tab for a group is a little misleading, as it does not let you view the members of the group. To see if a user is a member of a group, you have to select the user and view its Groups tab. WebLogic allows you to add groups to other existing groups, and the Membership tab lists all subgroups that are contained within the selected group. You can also use this tab to add another group to the current group.
Group membership places two important implications on your security configuration. Imagine you've defined two groups, A and B, in your domain, where group B is a member of group A. This means that:
When you view the Groups tab for a user, the Administration Console lists only the groups that the user belongs to directly. So, if a user belongs to group B, the Administration Console lists only group B under the Groups tab, even though the user actually belongs to both groups A and B.
When you create a new domain using the Configuration Wizard, the following
groups are created automatically and are ready for use:
Administrators, Deployers,
Operators, and
Monitors. Initially, the System user is the only user created, and it is
also the only member of the
Administrators group in the domain.
Remember, groups simply ease the task of administration. If a user is a member of a
group, he is not automatically guaranteed any special privileges. A group inherits
access privileges only when it participates in a policy statement (either directly or
through a role). For example, the initial System user account acquires Administrative
access rights only because it is a member of the
Administrators group, which in
turn is a member of a (global)
Admin role, and a policy statement is in place that
grants access to all areas of the domain to the
Admin role.
Two groups are not listed on the Groups page, but are automatically made available to the security realm:
This group represents the set of all authenticated users. Any user that successfully authenticates itself is a member of the users group.
This group represents the set of all WebLogic users, including anonymous users. Any user, whether authenticated or anonymous, is a member of the group
These groups provide a convenient way for setting up the default access control. For
instance, a resource can be made accessible to all users through the policy statement
"User is a member of the group everyone." Alternatively, you can restrict access to
only authenticated users by defining the following policy on a resource: "User is a
member of the users group." You can also programmatically check for group membership
on the server side. The following example checks whether the current user is
a member of the
users or
everyone group:
/** returns false if executed without any security context */
weblogic.security.Security.getCurrentSubject( ),"users");
/** returns true regardless of whether the user authenticates */
weblogic.security.Security.getCurrentSubject( ),"everyone");
WebLogic provides a user lockout facility to prevent abuse of user accounts. A user is locked out when a set threshold number of failed login attempts are made. When this happens, the user account is locked for a configurable period of time, or until an Administrator unlocks the user account. During this period, the user is prohibited from using those credentials to access the server. In order to configure user lockout, select the realm from under Security/Realms node in the left frame of the Administration Console. You then can use the User Lockout tab to adjust the lockout features and view lockout statistics.
Table 17-2 lists the various configuration options available under the User Lockout tab. By default, these settings are configured for maximum security.
Table 17-2. Configuring user lockout
|Lockout Enabled
|This setting indicates whether the lockout facility is enabled. You will need to disable this feature if you use an alternative Authentication Provider that supports its own mechanism for protecting user accounts.
|Lockout Threshold
|This setting determines the maximum number of failed login attempts that are permitted before the user is locked out.
|Lockout Reset Duration
|Suppose the Lockout Threshold is 5 minutes and the Lockout Reset Duration is 3 minutes. If a user makes five failed login attempts within 3 minutes, the user account will be locked out. If the five failed attempts do not occur within 3 minutes, the account still will remain alive.
|5 minutes
|Lockout Duration
|This setting determines the duration (in minutes) that a user will not be able to access his account after being locked out.
|30 minutes
|Lockout Cache Size
|This setting specifies the size of the cache that holds the invalid login attempts.
|Lockout GC Threshold
|This setting determines the maximum number of invalid login attempts that are held in memory. When the number of invalid login records exceeds this value, WebLogic's garbage collector removes all records that have expired— i.e., when the associated user has been locked out.
While a user is locked out, a Details link appears under the Locked column in the user list (under the Users node). If you select this link for any user in the list, you can view the number of failed login attempts for the user and the time when the last login attempt failed. You also can choose the Unlock option to manually reactivate the user's account.
Unlike a group, a role represents a dynamic collection of users. Role membership can be defined in terms of the following criteria:
You can specify a number of usernames. If the authenticated user matches one of the names in the list, and it satisfies all other criteria, it automatically becomes a member of the role.
Group names
You can specify a number of group names. If the authenticated user is a member of any of the groups in the list, and it satisfies all other criteria, it automatically becomes a member of the role.
Hours of access
You can define a number of time periods during which users are allowed access. If the user tries to access a resource during one of the time periods specified and satisfies all other criteria, it automatically becomes a member of the role.
You can combine these rules in various ways, using logical AND and OR relationships. For instance, you could create RoleA based on the criteria that the user belongs to the group UKSeller and hours of access are between 8:00 a.m. and 9:00 p.m. Any user who then tries to access a resource between these hours and also is a member of the UKSeller group will be a member of RoleA. Alternatively, you could create RoleB based on the criteria that the user belongs to the group UKSeller or the hours of access are between 8:00 a.m and 9:00 p.m. In this case, any member of UKSeller will always be in the role, and any user who tries to access a resource between 8:00 a.m and 9:00 p.m also will be a member of the role, regardless of the groups it belongs to. The membership conditions for the role are evaluated at runtime when a user attempts to access a resource that is protected by a policy statement defined in terms of that role. Thus, the membership conditions help evaluate whether the user is in the role at a point in time.
In general, WebLogic's default Role Mapping Provider manages the information about all the roles defined in a security realm. In fact, two kinds of roles can be defined: global and scoped roles.
Global roles are available to all resources within a security domain. A default set of global roles is created automatically when you create a new domain; it is used to grant access to various operations. These prefabricated global roles are associated with default security policies that implement the factory-set security configuration for your WebLogic domain:
Users that belong to this role have complete access to all areas of the domain. This includes the ability to view and edit the domain configuration, start and stop servers, deploy applications (EJBs, JMS factories, web applications), and more. Any user that belongs to the Administrators group automatically inherits the
Admin role. That is, the membership condition for the
Admin role is that the
user must belong to the Administrators group.
Users in this role are allowed to view the domain configuration, view and edit deployment descriptors, and deploy applications, EJBs, startup and shutdown classes, J2EE connectors, and web service components. The membership condition for the
Deployer role is that the user must belong to the
Deployers group.
Users in this role can view the server configuration, as well as start, stop and resume server instances. The membership condition for the
Operator role is that
the user must belong to the
Operators group.
Users in this role are allowed only to view the server's configuration. The membership condition for the
Monitor role is that the user must belong to the
Monitors group.
In order to create or modify existing global roles, select the realm from the left frame of the Administration Console and then select the Global Roles node.
WebLogic also provides a global role called
anonymous. Its membership is defined to
include all users in the
everyone group. Even though the
anonymous role does not
appear in the roles listed in the Administration Console, you still can use it to define
policies on resources.
Most roles are scoped, meaning that they apply to a particular resource or branch of a JNDI tree. Unlike global roles that are independent of any resource and can be managed centrally via the Administration Console, scoped roles are distributed across various resources. You have to select a particular resource in order to view the associated scoped roles. Regardless of the actual resource, the underlying principle for creating a scoped role is the same. Locate the resource from the left pane of the Administration Console, then right-click and select Define Scoped Role. In some cases, you can define scoped roles and their brethren, scoped policies, on even finer aspects. For example, you can define a scoped role and policy on a per-method basis for EJBs, on a per-operation basis for web services, and on an HTTP method type (POST, GET, HEAD, etc.) basis for web resources within a web application. Let's now look at how to create scoped roles for particular resources, and at some precautions you need to take during setup.
JDBC resources are located under the Services/JDBC subtree. You can right-click a chosen resource (e.g., connection pool) and select Define Scoped Role to define a role for the resource. You also can delete or modify previously assigned roles.
JDBC roles are hierarchical. If you right-click the JDBC/Connection Pools node, you can follow the same procedure to create a scoped role that is applicable to all connection pools.
You can assign a role to a specific node or branch of the JNDI tree for a server. Select the server from the left frame of the Administration Console, then right-click and select the "View JNDI tree" option. This launches a new browser window that lets you explore the JNDI tree for the chosen server. You then can select any node in the tree, right-click, and select the Define Scoped Role option.
The role and policy assignment for web applications is slightly different, in the sense that the roles and policies are scoped to particular URLs within the web application. Choose the web application from the left pane of the Administration Console and then select the Define Scoped Role option. You then will be asked to supply a URL pattern and a role that will be used to restrict access to the URL pattern. Later, you can apply a policy statement to the web application using the same URL pattern and scoped role. For example, you may wish to scope a role and policy to a particular servlet only, in which case you can use a URL pattern such as /servletname. If you want the role to apply to all resources in the web application, use the URL pattern /*.
Web service components are typically packaged in an EAR. You can locate the web service by expanding the node representing the application under the Deployments/ Applications node. In WebLogic 7.0, you can locate the web service from under the Deployments/Web Services node.
Right-click a service and select the Define Scoped Role option. This will let you define a role for all of the services in the selected web service module. You also can select the Define Policies and Roles for Individual Services option, which provides you with a table listing all web services. For each web service, you can choose the Define Scoped Role option to create a scoped role for that web service alone. When you define a scoped policy in this way, you also will be able to choose to which operations the policy should be applied.
The web service roles and policies are hierarchical. In essence, if you set up a role or policy on a web service module using the Define Roles option, all services within the module inherit the role and policy. You also can set a policy on the application that bundles the web service module. In this case, all web service modules and all web services within the modules will inherit the role and policy.
The assignment of scoped roles to EJBs is very similar to that for web services. If you select the EJB Modules node, any role or policy you define will be inherited by all EJBs. If you select a particular EJB module and choose the Define Scoped Role option, any roles you define will be scoped to all EJBs within that module. Finally, if you select the Define Policies and Roles for Individual Beans option, you will be presented with a list of EJBs, thus allowing you to assign the scoped role or policy individually to each EJB. If you define a policy for a particular EJB in this manner, you also can specify to which EJB methods the policy should be applied. An alternative approach to defining scoped roles for all the EJBs in an application is to simply define a global role instead.
To assign a scoped role to a JMS destination, select the JMS destination under the JMS server node that hosts it, right-click, and select the Define Scoped Role option.
For a J2EE component (e.g., EJB, web application), the role information also can be obtained from the deployment descriptors, as demonstrated earlier in the web application example. When you deploy a J2EE component, the roles are automatically created and populated with the data held in the deployment descriptors. If you subsequently make changes to the new security roles, these changes are not persisted back to the deployment descriptors. Ideally, once the J2EE component is deployed, you need to reconfigure WebLogic so that it doesn't refresh the roles when the component is redeployed. Later, we'll see how to alter this default behavior of the security providers by instructing them to ignore the security constraints in the deployment descriptors.
Recall how we used the weblogic.xml descriptor file for a web application to map the security roles defined earlier in the standard web.xml descriptor file to actual principals in WebLogic's security realm. For example, the following portion from the weblogic.xml descriptor file shows how to list the principals associated with the role mysecrole:
Alternatively, you could use the externally-defined* element to indicate to WebLogic that the security role defined in the web.xml descriptor file actually points to a role in the security realm created manually using the Administration Console. This approach means that you don't need to explicitly map the security role to existing WebLogic users and groups. Instead, you can defer the membership conditions for the security role until after the web application is deployed. For instance, suppose the weblogic.xml descriptor file for our web application includes the following security information:
This indicates that the security constraints for the web application's descriptor rely
on a role called
mysecrole that already has been configured for the realm. When you
deploy the web application, WebLogic will look for
mysecrole within its security
realm and use this security role to configure a policy statement on the web application.
In this case, the policy statement will specify the following condition: "Caller is
a member of the role
mysecrole." In this way, WebLogic can ensure that only users
who are members of the security role
mysecrole may invoke the protected resource.
Of course, mysecrole now must be configured for the realm using the Administration
Console, either as a global role or as a scoped role for this particular web application.
A similar technique can be used for EJBs.
An important benefit of the externally-defined element is that you don't need to modify the way in which WebLogic handles security information in the deployment descriptors (see the section "Ignoring the Deployment Descriptors" later in this chapter). Because the security constraints are implemented through a policy statement defined in terms of a security role that only can be populated using the Administration Console, there is no chance of overwriting this role and policy assignment. The major difference between this element and the traditional J2EE role assignment is that any security role assignment that lists the principals in the weblogic.xml descriptor file will create a role whose membership conditions are defined in terms of these principals. If you use the externally-defined element, the security role assignment must refer to a role that you've configured for the realm using the Administration Console.
Security policies let you protect a wide variety of server resources. For instance, you can decide who has access to the Administration Console, who can start and stop the servers, and who can access the connection pools, web applications, EJBs, enterprise applications, J2EE connectors, a particular branch of the JNDI tree, and more. Security policies offer very tight control over the authorization settings within the WebLogic domain. Although scoped roles look very similar to policies, policies define access control while roles do not. In summary:
A security policy uses a superset of the conditions that are available to a role. You can define a policy in terms of a logical combination of usernames, group names, time-of-day settings, and roles. The roles used in a policy can be either global roles, or those scoped to the resource for which you are defining the policy.
Note: A WebLogic resource is protected only when it has been assigned a security policy. Some WebLogic resources come with a set of default policies applied to them.
Whereas role information is stored by the Role Mapping Provider, policy information is stored by the Authorization Provider. Even though you may configure the security policies in the same way as the roles, we recommend that you set up roles to identify user responsibilities and create policies to specify access restrictions using these roles. That is, you should define roles in terms of existing users, groups, and time-of-day settings, and then you can use these roles to configure a policy statement for the resource. This scheme fits nicely with the J2EE role-based security model covered earlier in the section "Overview."
A policy can be assigned in a number of ways:
An Administrator can explicitly define security policies that help protect WebLogic resources. You can assign a security policy in the same way that you define a scoped role for a resource. Simply select the resource from the left pane of the Administration Console, then right-click and choose the Define Security Policy option instead. EJBs offer an additional option, "Define Security Policies and Roles for Individual beans," that allows you to define a policy for a particular EJB and to further limit this policy to selected EJB methods. Web service modules offer similar functionality, allowing you to define a policy for a particular web service within a module and to further limit the policy to selected web service operations. This same functionality exists for JMS destinations, whereby the policy can be limited to either a send, receive, or browse operation on a queue, or to a send or receive operation on a topic.
In WebLogic 8.1, new policies that you create using the Administration Console will, by default, not be applied. Instead, only those policies that were defined using deployment descriptors will be in operation. For example, if you add a new scoped policy for all .html files in a web application, and assuming that you had no such security constraint defined in the deployment descriptors, your new scoped policy will not be operational. To toggle this behavior, you need to select the security realm from the left pane of the Administration Console and then select the General tab. The Check Roles and Policies setting can assume two possible values.
Web Applications and EJBs Protected by DD
This option ensures that WebLogic honors only those security constraints defined in the deployment descriptors of web applications and EJB modules. This is the default behavior of the security realm. All Web Applications and EJBs This option ensures that WebLogic honors any security policies that are configured for the web applications and EJB modules using the Administration Console.
All Web Applications and EJBs
This option ensures that WebLogic honors any security policies that are configured for the web applications and EJB modules using the Administration Console.
Thus, you must change the value of the Check Roles and Policies setting to the latter option if you need to enable the policies defined using the Administration Console.
WebLogic supports the J2EE security model, which relies on the security roles defined in the descriptor files to determine access privileges. WebLogic's Authorization Provider examines the deployment descriptors when the EAR or WAR is deployed and creates internal security roles based on the configuration settings. In addition, the provider defines a security policy that grants access to all principals that belong to these roles. Later, we'll see how to alter the default behavior of the providers by instructing them to ignore the security data held in the deployment descriptors.
WebLogic comes equipped with a number of default security policies—for example, WebLogic supports a default policy that restricts access to the Administration Console. The following security policies are based on role membership:
Administrative resources
The Administration Console and other administrative resources are protected by a security policy that demands that the caller be in one of the following roles:
Admin, Deployer, Operator, or
Server resources
Resources under the Server node in the Administration Console are protected by a security policy that demands that the caller be either in the
Admin or
COM resources
Resources under the Services/jCOMnode in the left pane of the Administration Console are protected by a policy that demands that the caller be in the
By default, all application-specific resources, such as those related to JDBC, JMS,
EJB, EIS, MBean, and Web Services, are accessible to all users. This is possible
because these resources are protected by the default policy, which demands that the
caller be in the
everyone group. You can always view the default security policy that applies to a WebLogic resource. For instance, if you right-click the Connection Pool node under the Services/JDBC node and then choose the Define Security Policy
option, you can view the default policy for all connection pools.
When you configure a new resource—for example, a new JDBC pool or a web services component - it automatically inherits the default security policy. Any new security policy associated with a resource also uses the inherited policy conditions. However, if you define a new security policy for a resource with new policy conditions, these settings override the inherited policy conditions. That is, if you define a policy for a resource, the inherited policy conditions are ignored. For instance, if you define a policy constraint for a JDBC pool that requires that the caller be in the role MyRole, it overrides the default policy constraint that the caller be a member of the group everyone.
When an application is deployed, WebLogic inspects the security constraints defined in the deployment descriptors and sets up the appropriate role and policy statements in the various providers. Because these roles and policy statements are not persisted to the deployment descriptors (but rather to an internal store), reading this information from the descriptor files the next time the application is deployed means that WebLogic may overwrite any changes that you make to the role and policy information. You can prevent this overwriting behavior by instructing WebLogic to ignore the security constraints in the deployment descriptors the next time the application is deployed. To configure this, navigate to the security realm using the left pane of the Administration Console, and then in the General tab change the value of the On Future Re-Deploys* attribute. The default value for this setting—i.e., initialize roles and "policies" from DD—ensures that WebLogic does create the roles and policies based on the security information held in the deployment descriptors. If you set the attribute to "ignore roles and policies from DD," you can prevent WebLogic from reading the security information held within the deployment descriptors.
Because the providers manage all the information about the roles and policy statements, you have greater control over this access control information now that you can decide when WebLogic should ignore the security data in the deployment descriptors. You have two basic options, each with their own security implications:
If you choose to ignore the deployment descriptors before actually deploying an application, the security constraints for the application need to be configured manually from the Administration Console. The providers will persist the access control information in their own stores, and the security data in the deployment descriptors will be ignored completely.
If you choose to ignore the deployment descriptors after deploying the application, the providers already will be populated with the security constraints in the descriptor files, which you can later further refine from the Administration Console. Once again, the providers will store this information in their own stores. However, because the security settings in the descriptor files have been ignored, they can no longer override any changes you've made to the roles and policy statements.
Figure 17-1 summarizes the security architecture that we have just described.
As you can see from the figure, users may belong to groups, and groups may contain other groups. Roles may be defined in terms of users and/or groups. Roles can either be global or scoped to a particular kind of resource. Here we haven't shown all resources—just the hierarchical connection pool resources. A particular connection pool is contained in the Connection Pools resource.
Note: Strictly speaking, policies are applied to a
ResourceMBean. At runtime, a
ResourceMBean will exist that represents each actual JDBC Connection
Pool, all of which extend to another MBean that represents the "container"
holding all of the connection pools. Inheritance of policies
works because the
ResourceMBean extend each other in this way.
Scoped roles and policies may be associated either with the Connection Pools container (in which case it is inherited by all its instances), or with a particular JDBC Pool itself. All policies are scoped because they are always associated with a particular resource.
Next week's excerpts from Chapter 17 of WebLogic: The Definitive Guide will cover WebLogic's various security providers and their default implementations, along with a look at how to authenticate using JAAS, and examples of Authentication and Identity Assertion Providers.
Avinash Chugh, Jon Mountjoy presently works as Senior Development Manager for a firm that produces software for the regulated industries (finance, energy, pharmaceutics).
Return to ONJava.com.
Copyright © 2017 O'Reilly Media, Inc.


text:
OWENS MILLS, MARYLAND -- Date night 07/04/2016, arrived 6pm for dinner, was seated quickly, and was told that the bar server would take care of our table. She served the salad and the first round of drinks and bread. She then returned to the bar area and she did not come back to clean table or refresh the drinks or even to check if we needed anything. We sat there for almost an hour. No one came to the table and there were at least two more ladies on the other side and a young man serving the same row we were sitting except our table, and yes everyone was eating and drinking.
As time went on the cook was the one who brought it to someone attention that there was dinner to be served and it had been sitting for too long. Another server and we saw him give the food to her. She question the bar server, who then had her deliver it to us. Food cold, my pasta was sticky, fries were cold, and then the bar server came to the table. I question her about who was supposed to serve this table and I also spoke with the hostess in charge. It was the holiday and she said they were short, which had nothing to do with me. She give a 20% discount which was nothing. This place has no love for the customers and I will never return.
LUFKIN -- Have been to Red Lobster on several occasions and found each time we have to wait to be seated. Even if you are there at 11 AM, first one, they still make you wait to be seated. No customer service AT ALL. Went on Sunday after church, usually full but this time not so. But still waited over 10 minutes. One family complaining another left. When we finally got seated (just me and my husband) there were 6 tables in our section empty. That is so wrong for a nice restaurant like that. People should never have to wait if you have that many empty tables. What is wrong with this restaurant. It is a shame. We love it but we are done. You guys need to get it together or close your doors.
LANHAM, MARYLAND -- My family and I had the opportunity to visit Red Lobster on Wednesday April 8, 2015 at 6:45 pm. We were greeted by a hospitable hostess who seated us within ten minutes of our arrival. Our first observation was the cleanliness of the restaurant, followed by the warm salutations from our server. Our delicious dinner was very hot, appetizing and with low sodium. Unlike some other restaurants, we felt like royalty.
Our choice to dine at Red Lobster was somewhat cautioned because of the previous unfavorable remarks we had discovered. We are indeed pleased that we elected to embrace this opportunity without any great expectations; and, we were totally misled. Thanks Red Lobster for a Memorable Dinner Experience! We plan to revisit your establishment very soon!
LAS VEGAS, NEVADA -- My wife and I have a date night 2 to 3 times a week. I know she had been wanting Red Lobster for a while so we went to the Red Lobster on valley view just off the 95 for dinner. Not busy just average only 5 min wait 45 min serve time food came incorrect no salads. They said "Sorry we forgot." They forgot my wife's shrimp scampi and my chicken was so overcooked it was like leather. For dessert we had the molten cookie and for a hot dessert the core was still frozen. All and all this food chain is forever removed off our list and will never go to from servers to food horrible and if there was a negative star I'd have given it to this place.
LIVERPOOL, NEVADA -- So we went to Red Lobster for my daughter's birthday yesterday, and let me tell you, the service was ridiculous! First of all, they refused to seat us for an hour even though they told is fifteen minutes max and slowly seated every other patron in the lobby. Seriously? Not okay. Then, since we explicitly told them it was my daughter's birthday and we witnessed them giving a free slice of cake and song to two other birthday-celebrating patrons, what do we get? A bill and a nudge to go home. That's it, no cake, no song, no seats. Is it because we're Chinese? Is it because we look foreign? I have no idea but this is ridiculous. So if you are a minority, never, ever go to Red Lobster.
ALTAMONTE SPRINGS -- On Monday, Dec. 9, 2013 my family of 10 took me to dinner for birthday. I arrived first asking the Hostess for table for 10. Her respond was, "you will have a one hour wait." I asked why because business was slow and I seen tables everywhere. They had closed off one side of the restaurant so you waited the one hour or ate elsewhere. Are you serious?
I am in the restaurant business and a known restaurant like Red Lobster, in the holiday season and normally a packed place, you are told to wait an hour is totally unacceptable. No way of communicating with some of my party, to have them go somewhere else, we waited and actually enjoyed the meal but still couldn't forget the welcome we got.
You never tell a customer what they don't want to hear. You kill them with respect and kindness. Service was excellent and meal was outstanding, but closing down half of restaurant and telling people either wait for tables to clear or they couldn't accommodate you is very unprofessional. Never in my life have ever put a complaint to a restaurant, but my feelings are this should have never happened.
WHITEHALL, PENNSYLVANIA -- Customers be careful charging your dinner at Red Lobster. Review your charge on your computer. We had given a generous tip & paid for our dinner on my Capital One Visa. Noticing a $2 (more) difference from my copy of the dinner bill and what has been posted on the computer.
I called the restaurant to inform the manager that we had dinner there 2 days ago, and told her about the error. It seems the original bill has already gone to Headquarters, & I had to deal with headquarters. It's not the money but the principle. Knowing the red tape I had to deal with I decided not to contact Red Lobster's headquarters. Just think if this is done on all charged dinners. Again watch your bill.
FAYETTEVILLE, NORTH CAROLINA -- Walked in place smells like mold and dirty socks! Really needs a good cleaning place is very nasty! Had to move my seat three times to try to avoid smell! Had to sit just about all the way in the back to escape smell and when I left felt as if I needed a shower and change clothes!
Will not return until place is under new management cause whoever is the GM now obviously needs fired and replaced with someone who knows what it takes to keep place clean and fresh smelling! If you plan on going to this place bring respirator you will need it! Save your time and money go elsewhere! They just built a Bonefish Grill go there! Red Lobsters over 30 yrs old probably needs torn down and rebuilt!
DECATUR, ALABAMA -- On Jan. 4, 2014 a friend and I went to Red Lobster for dinner, what a mistake that turned out to be. The food was not the normal standard for such a prestigious place. Most of the menu has been downsized and the food was what one would expect to find at a low class chain. Disappointed is not exactly the correct word to use for the experience we had.
The waitress was nice enough, however the food was lousy, not to mention the price was outrageous for what they served. They have changed the inside dining rooms from what was an experience itself to a run of the mill plain ole table and chairs with no motif, the lobster tank was nasty... and they think people would want to eat one of those.... sorry to say I won't be back!

subset: commoncrawl


text:
Richard Childress Racing
Recent News
Charter Airing Childress Institute for Pediatric Trauma PSA Featuring Richard Childress
May 2, 2013
WINSTON-SALEM, N.C. (May 2, 2013) – Charter, the nation's fourth largest cable operator, is airing The Childress Institute for Pediatric Trauma's public service announcement to raise awareness about the No. 1 killer of children in America – serious injury. The PSA will run on select cable channels in Charter's service areas throughout the U.S. from now until May 26.
"Serious injuries kill more children in America than cancer, birth defects and heart disease combined," said Richard Childress, president and CEO of Richard Childress Racing and co-founder of the Childress Institute for Pediatric Trauma. "It is our mission to save the lives of injured children across the United States by improving the treatment of critically-injured children. The Childress Institute for Pediatric Trauma is grateful to Charter for helping us raise awareness of pediatric trauma as a healthcare crisis."
Serious injuries can happen anywhere at any time to any child. The Childress Institute for Pediatric Trauma wants to help every injured child receive the best care, no matter where or how they get hurt.
View the PSA by visiting the Childress Institute's YouTube channel at www.youtube.com/ChildressInstitute. Fans can help save the lives of injured children by texting WIN to 80077 to donate $10. When prompted, reply YES to confirm. (See terms below).
Media Contact: Kara Thompson, email@example.com, (336) 491-9766
About the Childress Institute for Pediatric Trauma
The Childress Institute for Pediatric Trauma's mission is to lead national efforts to reduce death and disability following injury to children less than 18 years old. Life-threatening injury is the No. 1 killer of kids in America. Nearly 10,000 children die each year – more than all other causes combined. The Childress Institute invests resources in research, education and awareness to improve the treatment for critically injured children in the U.S. The Childress Institute for Pediatric Trauma at Wake Forest Baptist Medical Center was established through the generosity of Richard and Judy Childress. For more information, please visit www.InjuredKids.org.
About Charter
Charter (NASDAQ: CHTR) is a leading broadband communications company and the fourth-largest cable operator in the United States. Charter provides a full range of advanced broadband services, including advanced Charter TV® video entertainment programming, Charter InternSet® access, and Charter Phone®. Charter Business® similarly provides scalable, tailored, and cost-effective broadband communications solutions to business organizations, such as business-to-business Internet access, data networking, business telephone, video and music entertainment services, and wireless backhaul. Charter's advertising sales and production services are sold under the Charter Media® brand. More information about Charter can be found at charter.com.
About Donations
$10.00 donation to Wake Forest University Health Sciences benefitting the Childress Institute for Pediatric Trauma. Charges will appear on your wireless bill, or be deducted from your prepaid balance. All purchases must be authorized by account holder. Must be 18 years of age or have parental permission to participate. Message and Data Rates May Apply. Text STOP to 80077 to STOP. Text HELP to 80077 for HELP. Full Terms: www.mGive.org/T. https://mgive.org/Privacy.aspx


text: SOUTHWEST AIRLINES ANNOUNCES NEW ROUTE: PITTSBURGH INTERNATIONAL AIRPORT – HOUSTON HOBBY AIRPORT PITTSBURGH, PA (October 22, 2012) – Beginning today, travelers can book new nonstop flights from Pittsburgh International Airport to William P. Hobby Airport in Houston, Texas, on Southwest Airlines. Flights will depart daily beginning April 14, 2013. Flights can be booked at southwest.com. "We are very pleased that Southwest has added a new destination. The Houston, Texas market is vital for our business and leisure travelers and increasing the choices teamed with Southwest's competitive fares will be a great benefit to our region," said Allegheny County Executive Rich Fitzgerald. "The Airport Authority is thrilled to be able to share in the announcement because this is the first time nonstop daily Pittsburgh flights to Houston Hobby Airport have ever been offered! Pittsburgh is pleased to be a part of Southwest's expansion program in Houston," said David Minnotte, Chairman, Allegheny County Airport Authority. "With every schedule extension, we look for ways to optimize the performance of our routes. We're excited to offer the new nonstop service between Pittsburgh and Houston which will provide our customers convenient connecting service to/from the east, west and gulf coasts. Customers will also experience our newly retrofitted 700-series aircraft with the Evolve interior on these routes," stated Michelle Agnew, Southwest Airlines spokesperson. Southwest Airlines is building a $100 million international facility at William P. Hobby Airport (HOU) and will begin operating flights to Mexico, the Caribbean and other Latin American destinations in 2015. The PIT-HOU schedule beginning April 14, 2013 will include one flight daily. Monday through Friday, it will depart PIT at 11:50 am, arriving HOU at 2:00. Saturdays it will depart PIT at 9:15 am and on Sunday depart PIT at 12 noon. Returning from HOU to PIT: Sunday through Friday, the flight will depart HOU at 1:35 pm and arrive at PIT 5:35 pm. Saturday, it departs HOU at 10:35 am and arrives at PIT 2:29 pm. Southwest recently announced that it would also offer seasonal flights to West Palm Beach, Florida (PBI) beginning February 14, 2013. The non-stop West Palm Beach flight departs PIT daily at 6:55 am and arrives at PBI at 9:30 am. The return flight departs PBI at 12:30 pm and returns to PIT at 3:00 pm. Saturday's return trip arrives at 2 pm. Southwest and AirTran Airways currently operate 28 combined daily flights from Pittsburgh to Atlanta, Baltimore, Chicago Midway, Denver, Ft. Lauderdale, Ft. Myers, Las Vegas, Orlando, Phoenix and Tampa.


text:
(Sorry this is a little long)
My LO is 12 weeks old now, she's constantly changing the way she eats and behaves:
1) My mom is watching her during the day at work, she doesn't always give my LO her gas drops because she just doesn't think they're needed maybe? I always give them to her because she's so gassy – should I say something? Apparently my LO is overall good for my mom and sleeps well and is rarely fussy. (yesterday was a whole different story where she cried, didn't want to sleep or eat or be put down)
2) Sometimes LO gets so gassy she just cries and cries. I have not changed my eating habits in a few months (I did cut out dairy for a while in the very beginning) and some days she's great and then other days, I feel like a horrible mom because my daughter is in pain or uncomfortable. Is it me or is it just because sometimes she gets really gassy? Will this go away??
3) LO's latch has gotten worse over time and I don't know if it's something I'm doing or if this is just a "phase" she's going through or what. She will do a shallow latch and by the time we're done feeding, she's right on the nipple itself. She also will have a "smack latch" where she will just smack her lips on the breast – almost as if she's playing. She doesn't cry or scream at the breast currently which she did do a few weeks back.
4) With #3 said, when she eats, she latches on and off the whole time, waves her one free arm around like crazy (as if it has a mind of its own) and that causes her to un-latch even more. She also now has been rubbing her eyes and pulling on her ears because she's so tired which again, causes her to unlatch. Needless to say as well, she won't nurse to sleep anymore as of right now, is there something I can do to help the latching? I keep offering the breast until she just won't take it anymore. With such a poor latch, milk seeps out of her mouth and then she gets it under her chins (yes – plural ) and then her chins/neck gets really red and starts to get a distinctive smell. I put a burp cloth right under her mouth to catch that milk but it doesn't always seem to help and try to use a wipe to keep her clean.
5) She has recently started only eating from one breast in the wee hours of the morning and then both in the evening. I have to pump the other side, my question with this; the other side seems to produce a more white/watery looking milk than the other side. Is this normal? It also seems like it takes twice as long to "empty" that breast than the other while I'm at work and having to pump. Lefty and I are ready to go but we have to wait on Slow Poke Righty.(I have a Medela PISA)
6) This doesn't have to do w/ nursing but my husband's mother. Over a recent weekend, we went to visit his parents (they live about a hour and half away), his mom kept making comments about how EVERYTHING my daughter did, her daddy did when he was a baby. It was EXACTLY what he did. The way she looks is EXACTLY how her daddy looked. Because him and his sisters and my husband's nieces and nephews liked car rides and swings, his mom is shocked to the core that my LO does NOT like them. Also, his mom seemed put out that LO cried everytime she tried to hold her and just couldn't believe that LO was already attached to me and my husband (more me than him). I feel like his mom resents me or doesn't like me and refuses to see any part of me in my daughter. We were there Friday-Sunday and she commented multiple times/random times during the weekend how much my daughter was just like her dad. It upsets me very much, should I say something next time and upset my husband who disagrees with my feelings or just let it go because I'm overreacting or what? His mom also I think gets upset because I leave the room to go nurse when they gave me a nursing cover at my baby shower.


text:
Register for a FREE GoComics account and get this, plus any other
comic strip delivered daily to your personalized My Comics Page (homepage
and free mobile app).
Upgrade to a GoComics Pro account (only $19.99/yr) and have all of your
favorite comics emailed to you daily! You'll also get unlimited archive
access to decades of comics and an ad-free website and mobile app
Custom Comic Home Page
Create a collection of your favorite strips.
Comment, share, interact with other comic fans
Account/preferences access on theGoComics mobile/tablet app.
You must be signed in to make a comment.
Silly family antics and goofball humor, the Drabble family tickles readers' funny bones with outrageous antics. Kevin Fagan's lighthearted family strip chronicles the zany mishaps of his offbeat characters, especially goofball college student Norman Drabble and his donut-eating father Ralph. One of the best-loved families in the comics, the Drabble clan also includes smart younger brother Patrick, precocious little sister Penny, and June, the Drabble matriarch best known as "Honeybunch."
From Norm's relentless pursuit of his dream girl to Ralph's hilarious power struggles with Oogie the cat, Drabble is always full of witty, wacky and wonderful humor. The genuine love that keeps the Drabbles from driving each other crazy makes it one of the best family comic strips around, and the loony things they do make it one of the funniest.
© Kevin Fagan - All Rights Reserved.
Copyright © 2016. Universal Uclick, All rights reserved.
Terms & Conditions - Privacy Policy
Sign Up for Free
Sign In


text:
Tixdaq is the UK's leading ticket search engine Nottingham Forest tickets. We search all the major ticket vendors in the UK to bring you the widest choice of Nottingham Forest tickets from both the primary and secondary ticket markets. Simply search for the artist, theatrical performance, stand-up comic or sports event or browse the full listings on any category page to find the right ticket for you.
Nottingham Forest Tickets
Nottingham Forest tickets are available to compare and buy to the match of your choice. We have access to plenty of Nottingham Forest tickets so whether they are playing home or away compare and buy Nottingham Forest tickets online now.
We know you love your football so we have provided you with all the ticket information you need to watch your favourite team in action.
Whether you want Manchester United tickets or Inter Milan tickets, Barclays Premier League tickets or SPL tickets - browse our website and compare and buy football tickets online now.
Soccer tickets are available to compare and buy online now.
Upcoming Nottingham Forest Matches
There are no events currently listed for Nottingham Forest
Fulham v Spurs tickets available for this Saturday
AVB's Spurs travek to Craven Cottage this Saturday and we can confirm tickets to see Fulham vs Tottenham are still on sale.
Newcastle United vs Manchester United tickets available from £36.00
Cheap tickets to see Manchester United take on Newcastle United on 7th October 2012.
Chelsea star Torres makes swipe at former club Liverpool
Chelsea striker Fernando Torres says Liverpool's future is not bright.
Manchester United will sign Sneijder for less than 30 million pounds, says agent
Internazionale star Wesley Sneijder could move to Manchester United for far less than expected
West Brom boss 'delighted' with survival
West Brom manager Roy Hodgson has praised his team after yesterday's win against Aston Villa all but secured the Baggies' Premier League status.
Tottenham boss demands goal-line technology
Tottenham manager Harry Redknapp has said that the lack of goal-line technology is "unbelievable", following yesterday's defeat at Chelsea.
Arsene Wenger 'more frustrated than ever'
Arsenal manager Arsene Wenger has said that this season has been the toughest he has experienced since joining the clun in 1996.
Andy Carroll to miss Newcastle reunion
Liverpool striker Andy Carrol is set to sit out the match against old club Newcastle because of a knee injury.
Title race not over, says Alex Ferguson
Manchester United boss Sir Alex Ferguson believes the Premier League title race is still alive, despite his team's six point lead with just four games to play.
Thomas Vermaelen declares himself fit for league run-in
Arsenal's Thomas Vermaelen has said he has recovered from an Achilles tendon injury and is ready to return to action.
Tottenham still in fourth place race, says Harry Redknapp
Tottenham manager Harry Redknapp believes his team are still in with a chance of grabbing fourth place in the Premier League and reaching the Champions League once again.
Harry Redknapp says star players will not leave
Harry Redknapp has asserted that none of his Tottenham stars will be leaving the club, even if Spurs fail to qualify for the Champions League next season.
Tottenham must finish fourth, says Garth Crooks
Former Tottenham star Garth Crooks has stated that Spurs must finish in the Premier League top four if they want to continue to improve as a team.
Roberto Mancini 'surprised but happy' with important win
Manchester City boss Roberto Mancini has stated that he was surprised after his team dominated Sunderland in a 5-0 victory yesterday.
Mohammed Al Fayed defends Fulham's Michael Jackson statue
Mohammed Al Fayed has told fans they can "go to hell" if they do not like the new statue of Michael Jackson outside Fulham FC's Craven Cottage stadium, according to BBC Sport.
Carlton Cole fools media
West Ham striker Carlton Cole has pulled an April Fools' joke on twitter, catching out many national news websites.
Liverpool encouraged to buy Asian players
Liverpool's sponsor has said that the club should look at signing Asian players to take advantage of commercial opportunities in the region.


text:
Goddard workers call for changeSeptember 12,2013
Staff Report
PLAINFIELD — Members of the faculty and staff at Goddard College have issued a solidarity statement after the announcement that President Barbara Vacarr will step down in December.
In July, the school said Vacarr would be leaving to deal with family issues, including her daughter's health after giving birth.
The statement signed by 142 staff and faculty members embraces the presidential transition and calls upon the board of trustees to "engage with a full range of college constituencies."
The steps the statement asks the board to take up include: "refocus college resources and priorities to offer maximum support to our academic programs; restore confidence in financial leadership by creating a credible plan to improve enrollment, replacing expensive outside consultants with abundant in-house talent, and taking other needed steps to reduce administrative overhead; encourage open debate about college policies while refraining from actions, such as the monitoring of employee emails, that cast a chilling effect on healthy discussion; recommit to faculty shared governance over academic matters, including curriculum and restructuring."
The faculty and staff are currently negotiating union contracts — a renewal for the faculty and a first contract for the staff after voting to unionize in January. Both faculty and staff are members of UAW Local 2322 based out of Massachusetts.MORE IN This Just In
BARRE TOWN — Firefighters faced a collection of adverse conditions as a house... Full StoryWILLISTON Police are asking for help identifying the man who tried to steal roughly $800 worth ... Full StoryNEWBURY Police said somebody stole booze and change from a Welch Road residence. Full Story
- Most Popular
- Most Emailed


text:
If you closely follow open source or Java programming, you may have heard some of the buzz surrounding Eclipse. Eclipse is an extensible, open source IDE (integrated development environment). The project was originally launched in November 2001, when IBM donated $40 million worth of source code from Websphere Studio Workbench and formed the Eclipse Consortium to manage the continued development of the tool.
The stated goals of Eclipse are "to develop a robust, full-featured, commercial-quality industry platform for the development of highly integrated tools." To that end, the Eclipse Consortium has been focused on three major projects:
The Eclipse Project is responsible for developing the Eclipse IDE workbench (the "platform" for hosting Eclipse tools), the Java Development Tools (JDT), and the Plug-In Development Environment (PDE) used to extend the platform.
The Eclipse Tools Project is focused on creating best-of-breed tools for the Eclipse platform. Current subprojects include a Cobol IDE, a C/C++ IDE, and an EMF modeling tool.
The Eclipse Technology Project focuses on technology research, incubation, and education using the Eclipse platform.
The Eclipse platform, when combined with the JDT, offers many of the features you'd expect from a commercial-quality IDE: a syntax-highlighting editor, incremental code compilation, a thread-aware source-level debugger, a class navigator, a file/project manager, and interfaces to standard source control systems, such as CVS and ClearCase.
Eclipse also includes a number of unique features such as code refactoring, automatic code updates/installs (via the Update Manager), a task list, support for unit testing with JUnit, and integration with the Jakarta Ant build tool.
Despite the large number of standard features, Eclipse is different from traditional IDEs in a number of fundamental ways. Perhaps the most interesting feature of Eclipse is that it is completely platform- and language-neutral. In addition to the eclectic mix of languages supported by the Eclipse Consortium (Java, C/C++, Cobol), there are also projects underway to add support for languages as diverse as Python, Eiffel, PHP, Ruby, and C# to Eclipse.
Related Reading
Java In a Nutshell
Platform-wise, the Eclipse Consortium provides prebuilt binaries for Windows, Linux, Solaris, HP-UX, AIX, QNX, and Mac OS X. Much of the interest in Eclipse centers around the plug-in architecure and rich APIs provided by the Plug-in Development Environment for extending Eclipse. Adding support for a new type of editor, view, or programming language is remarkably easy, given the well-designed APIs and rich building blocks that Eclipse provides.
With hundreds of plug-in development projects in progress, industry giants like IBM, HP, and Rational (just acquired by IBM) providing resources, and design heavy-weights like Erich Gamma helping to guide the process, the future indeed looks bright for Eclipse.
By now you're probably wondering where you can get a copy of Eclipse for your platform and what you have to do to install it. The first thing you need to do is make sure you have an appropriate Java runtime available. Though Eclipse can compile your code for either 1.3 or 1.4 VMs, current versions were designed to run on a 1.3 VM. If you're not sure where to find an appropriate Java VM for your platform, you can find more information at eclipse.org.
Once you have a Java VM, you're ready to get Eclipse. Visit the Eclipse downloads page and grab the latest release build for your platform. All builds are delivered as .zip files. Unzip the archive into an appropriate directory and then read through any files that may be present in the readme directory.
Believe it or not, your install is now complete. If
you've installed your JVM properly and unpacked the Eclipse
archive correctly, you should be ready to run Eclipse for the
first time. All binary distributions provide a launch
application in the primary eclipse
directory. The name of the launcher changes from platform to
eclipse.exe on Windows,
eclipse on Solaris, and so on. The first time
the Eclipse application is run, it will complete a few
remaining install tasks (i.e., creation of a
workspace directory for storing project files)
before the environment comes up.
Once you have Eclipse installed and running, it's time to begin using it. After you initially launch Eclipse, you should see a window which looks something like this:
Initial Eclipse window layout (You can click on the screen shot to open a full-size view.)
As you can see, the Eclipse IDE has a fairly standard menu bar:
and toolbar:
There is also a tabbed editor, currently showing the
Welcome page:
The File Navigator, Code Outline, and Task List are present, but don't contain any data yet. In order to continue our exploration of Eclipse, we'll create a simple Swing-based calculator program.
Select File->New->Project... to begin creating your first Java project. In the wizard that appears, select Java from the list of possible project types in the left-hand list and Java Project from the right-hand list, then click the Next button.
First page of the New Project wizard
For the project name, enter Calculator, then click the Next button again.
Second page of the New Project wizard
The final step of the wizard allows us to specify where source code and class files should live, specify any subprojects which might be needed by the current project, and any provide any libraries that may be necessary for the build. Select the Use source folder contained in the project radio button, then click the Create New Folder... button. Enter src for the name of the new folder. Click Yes when Eclipse asks if you want to update the Build output folder to Calculator/bin.
Third page of the New Project wizard
Click the Finish button to have Eclipse create the project.
Once your project has been created, you may notice that the layout of the Eclipse window doesn't look quite the same as it did before you created the project: the Outline view has been moved to the left side of the window, the Navigator has been replaced with a Package Explorer, and so on.
Java perspective (You can click on the screen shot to open a full-size view.)
This new layout is called the Java Perspective. A perspective, in Eclipse parlance, is a saved layout containing any number of different editors and views. Eclipse ships with a number of default perspectives (Resource, Java, Debug, etc.) that can be customized, or you can create completely new perspectives. Perspectives are managed using items from the Window menu or the perspective toolbar which normally appears along the left-hand edge of the Eclipse window.
The next step in creating our Java project is to create
the directories that will contain our source code. Switch
to the Resource perspective using Window->Open
Perspective->Resource. In the Navigator view,
expand the folder tree until you see the
node. Select this node, then choose the
File->New->Folder menu item. In the dialog that
appears, make sure that the src directory is
selected, then enter com in the Folder
Name field.
Creating large numbers of folders using the New Folder dialog can be a bit cumbersome. Luckily, Eclipse is just as happy to let you do the work using your favorite filesystem interface: command shell, Windows Explorer, etc. Use one of these methods to create folders named devious and calculator under the com folder. Once you've done this, select any of the folders in the Navigator view and select the File->Refresh menu item. Eclipse will examine the filesystem and update the project to match. At this point, your project should look something like this:
Folder creation complete (You can click on the screen shot to open a full-size view.)
One final note on file creation: in the early stages of a project, you may find yourself frequently running code, creating a new file or folder, adding some more code, compiling, and testing the code again. It's important to remember that the menus Eclipse displays are specific to a given perspective. So, when you switch to the Resource perspective to create a new file or folder in the Navigator view, you'll find that the Run menu, for instance, changes dramatically from the Run menu in the Java perspective. One solution to this particular problem is to use the Window->Show View menu to show the Navigator view in the Java perspective. If you want to make this a permanent change, you can use the Window->Save Perspective As... menu item to save your changes as either a new perspective or to replace the existing Java perspective.
Now that we have the directory structure in place, we can
begin adding code to our project. We'll divide our
calculator program into three different files:
CalcPanel.java, and
Calculator.java. Grab the
.zip archive and place these files in
the com/devious/calculator directory. Use
File->Refresh to update the Eclipse project.
Project with source files added (You can click on the screen shot to open a full-size view.)
CalcPanel.java handles most of the user interface
for our calculator.
Calculator.java handles setup
and launching of the GUI. Most of the important work happens in
CalModel.java, which implements the actual "mechanics" of
our calculator: responding to events, performing numerical
calculations, updating the display, and so on. The easiest way to
explore the code is by switching to either the Java perspective
or the Java Browsing perspective. Use the Open Perspective
item in the Window menu or click the Open button
on the perspective toolbar.
As you use the Package Explorer to browse the source code, you may notice that the Outline view seems a bit superfluous. You can click the X in the upper right corner of the Outline view to close it. Should you want to see it again, you can use the Window->Show View->Outline menu item to display it again. Those interested in a multi-paned source code viewer a la Smalltalk should give the Java Browsing perspective a try.
Java Browsing perspective (You can click on the screen shot to open a full-size view.)
So you've managed to download and install Eclipse, create a Java project, and add the folders and files needed for a simple application. Now it's time to see the application run. You'll need to use the Java perspective to complete the steps necessary to run the app:
In the wizard dialog which appears, select "Java Application" from the list of Launch Configurations, then click the New button.
(You can click on the screen shot to open a full-size view.)
Enter Calculator as the Name for the new configuration.
Click the Search... button and select
Calculator as the Main class, or simply enter
com.devious.calculator.Calculator in the text entry
(You can click on the screen shot to open a full-size view.)
Click the Run button to save the configuration and run the application.
Once you've created a launch configuration for the application, you can run it again using Run->Run History menu item or the Run button on the toolbar. If you spend enough time playing with the calculator, you'll notice that while it works pretty well, it does seem to have one major flaw: it won't do subtraction! Time to fire up the Eclipse source-level debugger and find the problem. If you've been following along with the examples, you should be able to debug the application using the same launch configuration defined earlier. Select Run->Debug History->Calculator to launch the application in the debugger.
When you launch your application for debugging, Eclipse automatically switches to the Debug perspective:
Debug perspective (You can click on the screen shot to open a full-size view.)
Since our problem seems to center around the subtraction
function, we'll set breakpoints in the event handler for the
minus key and the equals key. First, we need to switch
to the editing tab for the
CalcPanel class. (If you
don't have an open tab for
CalcPanel, you'll have to
switch back to the Resource or Java perspective, open the file
there, then switch back to the Debug perspective.)
Use the
Outline view to select the
method. Scroll down a few lines until you see the
case statement for the minus key (line 126). If you
double-click in the left margin at this line, you'll see that
Eclipse sets a breakpoint there. Scroll down a bit more and set
another breakpoint on the call to
in the handler for the equals key (line 138).
Breakpoint set (You can click on the screen shot to open a full-size view.)
Next, switch to the calculator window and click some of the
buttons. Something like
2 4 6 - should do the trick.
Once the debugger hits the breakpoint, you can use the buttons
in the toolbar for the Debug view to step into, over, or out of
If we step into the
setOperation method, we see
that it just saves the operation code to the
pendingOp field. Press the Resume button on the Debug toolbar to continue the execution of the program.
Tip: A common mistake for new Eclipse users is to press the Debug or Run buttons on the main toolbar rather than the Resume button. This will launch another copy of your application, rather than continuing the current one.
Now, click a few more buttons (e.g. "1", "2", "3") and then
the equals key. Once we step into the
calculate method, the problem is obvious: someone copied the code from the
OP_ADD case but didn't edit it to properly perform a subtraction rather than an addition. Problem solved!
If you happen to be running your application using a 1.4 JVM, there's one final step to our debugging example. Rather than exiting the app, changing the code, recompiling, and then starting another debugging session, we can fix the problem on the fly. With the debugger still running, change the problem line from:
setDisplay(previousValue + currentValue);
setDisplay(previousValue - currentValue);
Save the file, then press the Resume button to get the application running again. Use the calculator's C button to reset it, then try the same sequence of operations again. This time around, it works!
What we've just demonstrated is Eclipse's support for a new 1.4 feature called "HotSwap." The Java Platform Debugger Architecture (JPDA) now supports the ability to substitute modified code in a running application. This is particularly useful when starting your application, or getting to the point where it fails, takes a long time.
One very attractive feature of Eclipse is the speed with which product bugs and deficiencies are addressed. While Eclipse 2.0.2 is the current version of the product, the Eclipse Group is actively working toward the release of Eclipse 2.1. Monthly "milestone" builds (M1, M2, M3, etc.) deliver the latest stable feature set from Eclipse 2.1 to interested users. Among the features included in the latest 2.1 M3 build:
FIXME, and tagged comments in Java code
into items in the Tasks list.
It is this last feature which makes Eclipse particularly well-suited to Java application development and, in particular, Web application development. Eclipse brings together all of the tools a developer needs to be successful at Web application development: an extensible IDE, a standards-based compiler, remote debugging, Ant-based builds, JUnit-based testing, and plug-ins for communicating with most application servers and EJB containers.
Scott Storkel is an experienced programmer with over twenty years of experience, including object-oriented systems for the last twelve years and building enterprise-class Java web applications for the last four years.
Return to ONJava.com.
Copyright © 2017 O'Reilly Media, Inc.


text:
We'll never post without your permission.
Create your Etsy password
By clicking Register, you agree to Etsy's Terms of Use and Privacy Policy. Etsy may send you communications; you may change your preferences in your account settings.
Uh oh! You need to have cookies enabled to sign in.
Nice—you already have an Etsy account.
Forgot your password?
Forgot your username or email?
Reopen your account?
May 6, 2012
View Danielle's other Treasury lists
May 6, 2012
what a great list! Thanks for including me :D
A stunner Danielle!
deep, dark loveliness. thanks, d!
May 7, 2012
Great treasury!thank you so much for including my item!