Logon failure Issue | URLRedirect filter enabled

If your user logon flow is working fine in development environment and is failing once you get to staging or live. Essentially there is a configuration that needs to be defined in wc-server.xml for allowedDomain if the URLRedirectFilter is enabled.

The URL redirectfilter is enabled to prevent phishing attacks where a link from the current site would prevent the user from being redirected to a different site. It does need correct allowedDomain or else some of the functionality including logon starts failing.

Make sure in wc-server.xml in store definition has correct value  to domain or sub-domain value in the URLredirectfilter definition for store element.

alloweddomain name="example.com" 

Logs from Error for this scenario with login failure:

[6/22/12 12:34::024 EDT] 00000123 EJBMDOrchestr A   CNTR0117I: Container-managed ejbStore() call will be bypassed on bean: "WC_ejgrp#Member-MemberManagementData.jar#UserPasswordHistory" if it has not been modified in the current transaction.

[6/22/12 12:34:58:313 EDT] 0000023b CommerceSrvr  A ECActionForwardInstance isRedirectAllowed(String) CMN0207E The value of the parameter "URL" is not correct.

[6/22/12 12:59:59:254 EDT] 00000113 CommerceSrvr  E WCAuthenticationCookie getUserId CMN1039E: An invalid cookie was received for the user, your logonId may be in use by another user.

[6/22/12 12:34:28:727 EDT] 00000122 CommerceSrvr  A ECActionForwardInstance isRedirectAllowed(String) CMN0207E The value of the parameter "URL" is not correct.

[6/22/12 12:34:30:239 EDT] 0000045b CommerceSrvr  E WCAuthenticationCookie getUserId CMN1039E: An invalid cookie was received for the user, your logonId may be in use by another user.

[6/22/12 12:34:13:330 EDT] 00000245 CommerceSrvr  A ECActionForwardInstance isRedirectAllowed(String) CMN0207E The value of the parameter "URL" is not correct.

[6/22/12 12:34:15:141 EDT] 00000245 CommerceSrvr  E WCAuthenticationCookie getUserId CMN1039E: An invalid cookie was received for the user, your logonId may be in use by another user.

IBM Management Center | Preview not working

When you click on the preview functionality from the management center and it fails with the following error

[5/8/12 15:43:15:374 CDT] 00000026 SystemOut O ErrorDataBean:

Originating command:
Message Type: 0
Message Key: _ERR_REDIRECT_VIEW_ERROR
Message: CMN3101E The system is unavailable due to "URL".

[5/8/12 15:47:28:845 CDT] 0000002c CommerceSrvr E WCAuthenticationCookie getUserId CMN1039E: An invalid cookie was received

for the user, your logonId may be in use by another user.
[5/8/12 15:47:28:856 CDT] 0000002c SystemOut O ErrorDataBean:
Originating command:
Message Type: 1
Message Key: _ERR_INVALID_COOKIE
Message: CMN3101E The system is unavailable due to "{0}".

[5/8/12 15:49:06:561 CDT] 00000027 SystemOut O ErrorDataBean:
Originating command:
Message Type: 0
Message Key: _ERR_REDIRECT_VIEW_ERROR
Message: CMN3101E The system is unavailable due to "URL".

In wc-server.xml under respective WebModule all webserver hostname and domainname are added as AllowedHost

Cookie path creation always at the web server root !!

If you use the default settings on cookie, it creates the cookies at the web server context. In WebSphere commerce that would create the cookies at /webapp/wcs/stores/servlet with default settings. This is usually not a problem for most scenarios but if you have a scenario when there is a canonical URL e.g for SEO,  that does not start with /webapp/wcs/stores/servlet. The HTTP response stops carrying the cookies to the browser and you will start seeing issues in the site where you have code that depends on the cookie.

Sample code to create a custom cookie at the root:
String value="custom_cookie_value";

Cookie customCookie = new Cookie("CustomCookie",value);

customCookie.setPath("/");
Even though this is a simple thing to fix, it could be hard to debug. As a best practice, always create custom cookies at the root and out of the box cookies are always created at the root.


Primer on cookies:
A cookie is a application specific data stored as a separate file for each domain in the browser. There are 2 types, session cookies and persistent cookies. Session cookies are used to log information that are eventually erased after the life cycle of a session, e.g Based on a users Login, if you want to show certain attributes or mini-carts and are deleted on LogOff.
Persistent cookies are store for much longer period and are useful for things like RememberMe functionality.


Validation rules to pass the cookies back to web-server:
A cookie is sent back from browser to web-server based on certain events when it matches the Domain, Path and port of the server in cookie.
Cookie can have a secure attribute set if it is on HTTPS.
Each cookie has a Max-Age and the browser would not send back expired cookies.

Bazaar Voice Integration | Reviews and Ratings

BazaarVoice provides a really good platform for product feedback and social media integration's. It is really easy for business users and programmers to integrate with back end systems.

Essentially BazaarVoice Integration has the following main components:

1. Display reviews to guest and registered customers.
2. Writing new reviews and as a platform providing business users access to their workbench tooling to approve reviews.
3. This is optional and provides SEO benefits as the JS based integration makes it harder for search engines to crawl the content and hence BazaarVoice provides SEO basic and SEO advanced integration's, this is a server side include of product files.
4. Sending outbound XML product feed to BazaarVoice nightly or weekly feed of categories and products, depending on your product cycle.
5. Feeding reviews and ratings file from BazaarVoice back to your Search engine (Endeca or SOLR).  This is to improve the search on the site by allowing keywords from reviews to be searchable.
Find below sample code for a simple integration piece to show reviews.

Resources: Great place with examples.
https://github.com/bazaarvoice/HostedUIResources

Adding cache-control on static assets | Improve data integrity and performance

Static files (example: JS\CSS\HTML.) are cached by client browsers and if they don't carry cache-control directive in the HTTP-header, it is up to the browsers to determine, how often to check to check for updated value from server. Some times browsers could cache stale content for days.
This could cause the static file to be obsolete and pick from local browser cache and out of sync and could potentially result in broken pages and corrupt files.
The solution is to add cache-control directive to the web server configuration and this will force the browser to check for the updated version from the server when the time specified expires.
The functionality would essentially result in HTTP_STATUS code 200 when a file is modified and other wise would return HTTP_STATUS code 304

Testing the HTTP-Header changes:
You can using tamper data as Firefox plugin or fiddler for IE to look at the HTTP-header

Make changes to httpd.conf
1. Add the following at the end of LoadModule section in web server configuration file (httpd.conf).
        LoadModule headers_module modules/mod_headers.so
2. Add the following at the end of web server configuration file (httpd.conf).


Scenario1: [Browser cache not expired and file changed - File should be fetched with 200 response]
Scenario2: [Browser cache expired and file changed - should be fetched from server with 200 response]
Scenario3: [File not changed but browser cache expired - should get 304 response]
Scenario4:[File not changed and browser cache not expired - should be serverd from browser cache]

Sorting !!! an important function for a lot of display pages

This blog is for sorting using Java code. Sorting is an essential part, which is a required function in most code bases.I am going to start with a couple and then will add few more. If you any of you guys reading this have better ideas, please add in the comments.

//Sort a string with a delimiter and arrange with the same delimiter into a string Arrays.sortOf() uses merge sort and has a worst case performance O(nlogn)
//Sort and maintain the same ordering. LinkedHashMap is very useful to preserve the ordering. It Maintains a doubly-linked list running through all of it's entries

Introduction to WCS Cache Invalidation - Part 1

"There are only two hard problems in Computer Science: cache invalidation and naming things."
-- Phil Karlton

As the quote above suggests cache invalidation can be a complex topic.

In this post will discuss the basics of cache invalidation; along with some guidelines for the different invalidation strategies that can be used with WebSphere Commerce.
This guide assumes some familiarity with configuring caching in WebSphere.

What is cache invalidation ?

Essentially it is the mechanism of removing the stale items from cache.

WebSphere Commerce has a caching system called DynaCache.

Why is invalidation important?

To protect the accuracy of the data available in cache. 

Most business applications have a consistency requirement for certain types of data.

For example, If my inventory reaches zero, I don't want the customer to purchase items which have no inventory and which can not be back-ordered.

How can I invalidate cache?
Here is a list of the different ways you can invalidate cache:

1. Manual Invalidation
2. Time to Live (TTL)
3. Dependency IDs
1. Using command invalidation
2. Using CACHEIVL (only in WebSphere Commerce)
3. Using custom code

Manual Invalidation
This type of invalidation is done by using the WebSphere Commerce Cache Monitor.
The cache monitor is a web application which uses the DynaCache API to remove specific entries.

The EAR file comes with WebSphere Application Server but it is not installed by default.
Make sure servlet caching is enabled in your WCS environment before installing the Cache Monitor.

The advantage of this method is that you can invalidate all entries at the same time by pushing a button.
You can also invalidate only a given group of entries. This is a more complex topic which will be explained in a later post.

The disadvantage is that if you have a large number of entries it will be difficult to find a specific entry.
There is no search capability and the navigation is not very user friendly.

Invalidation using a TTL
The TTL value is configured in cachespec.xml.
A <timeout> child element is added to a <cache-entry> element. The timeout is specified in seconds.
This type of invalidation is best used when you don't have a hard consistency/freshness requirement.

Let's use the caching of the product display page as an example
For this example we will assume the following:

1. The product table is updated once a day
2. The update is done by a scheduled job
3. The scheduled job runs once a day at 10pm

In this case it would make sense to set the TTL for ProductDisplay to 86400 (seconds in a day):



The timeout starts from the time each cache entry is created. Each product has a separate cache entry which is created when a page for a specific product id or part number is accessed. Since each cache entry could be created at a different time, they could also expire at a different time.

The advantage of this method is that it is easier to configure compared to dependency ID invalidation.

The main disadvantage of using TTL invalidation is that there is no guarantee that the cache will expire before the product table is updated.

Here is a scenario where the cache would not be properly invalidated:

1. Most cache entries expire around midnight.
2. The scheduled job is delayed due to some problem.
3. A user access the product page for part number ABC at 12:30am creating a new cache entry
4. The scheduled job updates the data for ABC and finishes running at 1am
5. The product page for ABC is not updated because the timeout value was reset at 12:30am

Ideally the product update job should always run before the cache expires, but in this case it didn't.
The easiest solution in this case is to do a manual cache invalidation at 1am after the scheduled job has finished running.

Another disadvantage is that all the entries will expire around the same time. This will cause a large number of requests to hit WebSphere Commerce at the same time without the benefit of a cached response. This will degrade the performance perceived by the user.

In conclusion this method is best used when:

1. You have a low consistency business requirement: The cache can be updated sometime after the database is updated.
2. You have the operational resources: Someone is watching the scheduled job to see if it is delayed and if something goes wrong he knows to manually invalidate the cache.

NOTE: The <timeout> value is separate and different from the <inactivity> value. It is possible to have both settings. The <inactivity> value will expire the cache after it has not been accessed for a given number of seconds.

Stay tuned for the next post which will cover dependency ID based cache invalidation ...