Messages

Quoting from the link I sent you earlier:


Notice that the default build target compiles all the source files and creates the jars. It doesn't move the jars or create any wars.

If after building the jars you wish to move these to your webapp lib directories you should use the "copy_jars" target.

Take a look at https://www.konakart.com/docs/CustomizableSourceCode.html

The ANT target copy_jars moves the created jars to the webapps.

Just a word of caution...

When modifying the build.xml ANT file to define which class files go into which jars be very careful to ensure that classes only end up in one jar and not more than one.

The default build.xml ANT file ensures this is the case.

I refer back to my first reply... 

"Could it be that you simply aren't deploying the new class that is generated when you compile the modified BaseAction class?  Maybe you will have to modify the ANT build script to include your new class file in the target jar?"

If the class isn't being found by the ANT build it won't be added to any of the jars and then copied to your webapps.

Look for the missing class file after compilation. It might be called BaseAction$FeatureFlagSupport.class for example.  Did your new class file get included in the jar? I suspect not.  If not, you need to modify the ANT build file to add it to the required jar.


BTW. You probably don't want to create wars in your case (no need to run  ./bin/kkant -f ./build.xml make_wars).

Could it be that you simply aren't deploying the new class that is generated when you compile the modified BaseAction class?  Maybe you will have to modify the ANT build script to include your new class file in the target jar?

I think you really need to change the way you're approaching this.   With KonaKart the programming is all about the APIs.   Everything is available through the APIs.   You shouldn't need to look at the database at all.   You would only tend to do that for extremely special cases or perhaps for reporting purposes.

My advice would be to study the API examples.  Use the User Guide to work out how to run the examples (you use ANT).  From there, you could try to write a few simple programs that use the APIs so that you become familiar with using them. Once you're familiar with their use you will be able to do just about anything you want with your eCommerce store.

You need to take steps to ensure your installation of tomcat is not exposed to this vulnerability.

First of all, not all installations need the AJP Connector to be enabled.  If you don't need it... simply comment out the Connector in your tomcat's server.xml (you'll find that in the installation's conf directory).

The AJP connector is often used for communication between an Apache Web Server and Tomcat.   

If you use the AJP connector you must ensure that your firewall is configured to protect the AJP listening port from all locations that don't need access to it.  You should ensure your AJP port is not accessible from external IP addresses.

Note that not all versions of tomcat are affected.

It is certainly recommended that you upgrade to a version of Tomcat that has the fix.  Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later resolve the problem.

Hi,

It depends what status you use to determine a successful order.

You could look for that status id in the orders_status_history table (for the orders_id in question) and then look at the date_added column for that record.

Thanks for your suggestion Jon.  We'll add it to our list for consideration for a future release.

To see the responsive storefront in action you can view KonaKart Storefront Demo - if on a desktop machine watch what happens when the browser width is reduced.

For those starting out - this is a good place to start to get to know BIRT:  http://www.eclipse.org/birt/getting-started/

Simply replace KKWSEng with com.konakart.app.KKEng (for POJO), com.konakart.json.KKJSONEng (for JSON), com.konakart.jws.KKJAXWSEng (for JAXWS) or com.konakart.rmi.KKRMIEng (for RMI) .

Code Select Expand

EngineConfigIf engConfig = new EngineConfig();
engConfig.setMode(EngineConfig.MODE_SINGLE_STORE);
           
KKEngIf engine = new com.konakart.app.KKEng(engConfig);


You can also instantiate them by name if you wish:

Code Select Expand

/*
* Instantiate a java JSON Engine by name
* KKEngIf jsonEng = new KKJSONEng(engConfig);
*/
KKEngIf jsonEng = new KKEngineUtils().getKKEngByName("com.konakart.json.KKJSONEng", engConfig);


I don't know why you say the APIs are slow.  If used correctly the KonaKart APIs are efficient and fast.

SOAP, being a relatively heavy protocol, is always going to be a little slower than using POJOs or JSON, but still perfectly fast enough for most purposes.

You shouldn't instantiate your engines in the way you have described.

It's better to instantiate your engines like this:

Code Select Expand

EngineConfigIf engConfig = new EngineConfig();
engConfig.setMode(EngineConfig.MODE_SINGLE_STORE);
           
KKEngIf engine = new KKWSEng(engConfig);

If you do this you simply code against the KKEngIf which allows you to swap the engine at any time (including at runtime if required).  The implementation details are hidden from you by simply instantiating the engine for the required protocol (in the above case, SOAP).

(The equivalent is true for the KKAdminIf engines).

Thanks for reporting this. 

The tomcat bundle used for the v8800 and v8900 releases was the base package and not the Windows-specific packages.  It is in these Windows-specific tomcat bundles where you'll find tomcat8.exe etc..

We've made a patch that contains the files that you'll need to install KonaKart as a service in Windows.

Please see https://www.konakart.com/downloads/patch-releases/

You have to download the zip file, unzip the files into the bin directory of your KonaKart installation and then you should be able to install KonaKart as it describes in the User Guide.

As far as we are aware KonaKart is not vulnerable to this.

Some background:

CVE-2018-11776 was announced on 22/08/2018. Details were published ( https://semmle.com/news/apache-struts-CVE-2018-11776 ) by Semmle who found the vulnerability. It's a critical vulnerability because it involves remote code execution.

To determine whether you are vulnerable, here's a snippet from the above link:

For your application to be vulnerable to the attack vectors described below, both of the following conditions should hold:

• The alwaysSelectFullNamespace flag is set to true in the Struts configuration. Note that this is automatically the case if your application uses the popular Struts Convention plugin.
  
• Your application's Struts configuration file contains an <action ...> tag that does not specify the optional namespace attribute, or specifies a wildcard namespace (e.g. "/*")
  If your application's configuration does not meet these two conditions, you are likely not vulnerable to the two attack vectors described below.

In the standard KonaKart Struts storefront,  "alwaysSelectFullNamespace" is set to false because it hasn't been set to true in struts.xml and  the Convention plugin isn't used by KonaKart. Therefore, as far as we are aware the "out of the box" implementation should not be vulnerable. It may be wise to check your struts.xml file to determine whether the following line has been added, which would make you vulnerable:

<constant name="struts.mapper.alwaysSelectFullNamespace" value="true" />