With Oracle Commerce 11.0 – the the administrator username and password used by the deployment template is stored securely in the Oracle Wallet (i.e. the Oracle Credential Storage Framework or ‘CSF’) – y0u must have observed while deploying the application.
We usually have multiple environments DIT (development), SIT (testing), Stage, and Production.
So, In this scenario I’m assuming you have lost password for SIT or something happened which is blocking your access to the admin user. This is what I precisely faced couple of days back on one of the Endeca boxes. (It was a fresh install – still work was in progress to setup the test environment – no major work was performed in workbench – DOESNT MATTER AFTERALL does it?) – every bit of work is important
Tried to do the following:
1. Use the Manage Credentials script available in /endeca/ToolsandFrameworks/11.1.0/credential_store/bin folder to change the password to admin/admin –> the script does say it changed it successfully
2. Also, uncommented the ifcr=admin line in the webstudio.properties
3. Additionally added 2 properties username and password to workbenchconfig.xml
But, none of the above helped gain the access back to admin/admin. Switched the log-in mechanism to use Oracle Commerce SSO – and that helped log-into the workbench… but when we try to run any scripts such as set_editors_config.sh etc… it was again responding “401 access unauthorized – invalid credentials for workbench.
So, that’s kind of stalemate. Cannot export_site — so cannot import_site back.
Finally – I knew we have the same setup on another machine – so decided to go ahead and delete the folder named _ifcr (which contains all your workbench settings/applications etc…) – under /endeca/ToolsandFrameworks/11.1.0/server/workspace/state/sling.
Once deleted – restart Tools and frameworks service – it recreated the _ifcr folder (with a default of admin/admin) and was able to get back into the workbench.
And, then exported the site from development server – imported it into the testing server.
If you had changed the credentials using manage_credentials script to something other than admin/admin — you need to run the script again and change the password back to admin.
Restart both PS and TAF services.