Skip to main content

While I have not found a work around for getting the wizards to run properly with anonymous access enabled,  the code generated by the wizards seems to be running fine with anonymous access enabled.


Thus, it makes sense that if the business requirement states that intranet users who are logged onto a production SharePoint server as anonymous will be able to access certain select portions site, this can be done - it will not break K2 code.  However, you will not be able to complete the SharePoint wizards on this production box,  instead run the wizards against the development server (where anonymous access is not enabled) and simply export them to the production server when tested.

Anonymous doesn't apply to the design time execution of the K2 Studio Process and/or Event templates.  That only applies to a K2 Process that is being kicked off by a SP Document Library event (insert/update/delete...).  This is because the user who caused that SharePoint event to fire is not available to K2, thus the need to allow the K2 process to be kicked off anonymously.  The user is not actually logged into SharePoint anonymously. 


HTH


Reply