InstantASP Community Forums / Old Forums / InstantKB.NET 1.x / Suggestions & Requests / Additional Security Features / Latest Posts

RE: Additional Security Features

Carlos Muniz — Mon, 02 May 2005 09:57:05 GMT

Dear Richard,

I am forwarding your message to our development department for consideration for inclusion in the functionality of a later version. Thank you very much for your suggestion and please do contact me with any further ideas that come to mind.

RE: Additional Security Features

R1chard — Mon, 02 May 2005 07:35:34 GMT

Hi Ryan,

Is it still the plan to embed attachments within the database for v2 and have them searchable? That would certainly resolve a problem for me....

Enhancement/Security requests:

1) Expire date on users

2) Logging of logins/outs with IP address

3) Restrict userid to an IP address

4) Personal KB - only for me. Ability to add/edit/view articles within this element and Promote them to the admin for general inclusion

5) Workflow on approval process. Mark users as having contributor rights (to given categories if possible) so that they can submit articles to an admin who accepts, rejects or places them onhold.

BTW, if you put the elements in that you've talked about in here then your not charging enough ;)

Regards,

Richard.

RE: Additional Security Features

Ryan Healey — Thu, 11 Mar 2004 11:17:24 GMT

Hi Raphael,

R.a.d Spell is so easy to implement - this will certainly be within the v2.0 KB release. I need to chat wit the folks at Telerik with regards to licensing and protecting the control within my application but i'm sure this will be available

I'll certainly post more information once the BETA release is available

RE: Additional Security Features

NiM — Thu, 11 Mar 2004 11:12:19 GMT

Hello Ryan

Great! I also saw, that you distribute the InstantForum.Net 3.4 with r.a.d.Spell (very usefull component...) - is there also a chance, that you implement this in the new KB release (spellcheck for articles)?

And... Would be very nice, if I/we can test the beta before final release date!

Thank you,

Raphael

RE: Additional Security Features

NiM — Thu, 11 Mar 2004 10:36:06 GMT

Hello Ryan

Great! I also saw, that you distribute the InstantForum.Net 3.4 with r.a.d.Spell (very useful component...) - is there also a chance, that you implement this in the new KB release (spellcheck for articles)?

And... Would be very nice, if I/we can test the beta before final release date!

Thank you,

Raphael

RE: Additional Security Features

Ryan Healey — Thu, 11 Mar 2004 07:45:56 GMT

Hi Raphael,

Thank you for your suggestion. I quite agree this would be more secure. This is currently the way the forums work. I had planned to move all attachments to the database for v2.0 of the knowledge base. This will also provide the ability to search the attached documents within the knowledge base

With regards to a release date ETA is around end of Q2. Betas will of course be released before this time if you wish to be one of the first. We have many new features to add to this release. A list will be published to the forums soon for feedback before we begin development

RE: Additional Security Features

NiM — Thu, 11 Mar 2004 07:38:31 GMT

I would like to use kb.net as a "document (attachment) and article" management system. Is there a possibility to store the attachment inside the database? I think this is more secure, because no one can access an attachment which is just available for a granted user (request an attachment, check permission, send attachment if granted). Now, everyone can access an attachment in the http://server/instantkb/attachment folder (of course just with knowledge about the file name).

would be very nice... and more secure...

Is there a date, when next release/update will be available?

Raphael

RE: Additional Security Features

Ryan Healey — Thu, 04 Mar 2004 01:55:00 GMT

Hi Adam,

Thank you for your feedback. This sounds like a very interesting idea. It would certainly be nice to centralize state management into a manageable class. I'll look into this method a little further. It should be quite simple with the knowledge base to be honest as not to much state information is persisted. Thanks again - i may send you some early examples if thats ok to ensure i've not created any common problems your already aware off

Thanks again - all the very best and please do keen them suggestions flowing

RE: Additional Security Features

Adam Rogas — Thu, 04 Mar 2004 01:52:00 GMT

One method we have found quite useful is to forgo the session state altogether and using an HTTP module to override the page level USER object. This allows us to extend the build in user object to support any product specific user properties as well as gives us the ability to not rely at all on a Shared SQL Server or any other centralized state management. The roles are decode and retreived from the the authentication ticket so that we can extend the built in InRole() method in the User object. By using a module and extending the built in methods you could just switch out the HTTPmodules that were used to achieve the flexibility to support traditional or cookie based session state management.

I am sure by now you hate me.

If any of this seems if worth your while let me know and I would be more than happy to help in any way.

Thanks

Adam Rogas

RE: Additional Security Features

Ryan Healey — Wed, 03 Mar 2004 02:13:00 GMT

Hi Adam,

Thank you for your email. I can certainly understand your concern. One of my aims with v2.0 was to look at a centralized method to handle state management. I would certainly like implement a easy solution which would allow the users to choose from in-process, sql server based or stateserver session management.

I'm actually quite looking forward to developing v2.0 and have some big plans some of which are based around the authentication methods (i would like to offer support for active directory) and also the state management model used. The lessons i learn from the knowledge base in terms of providing multiple options for state management will also be applied to the forums.

I appreciate your concern and may contact you during the development process to ensure we are heading in the right direction and any major updates will not greatly impact your current modifications.

Thanks for your thoughts and suggestions. I'll certainly keep this topic upto date with any future developments

RE: Additional Security Features

Adam Rogas — Wed, 03 Mar 2004 02:05:00 GMT

I am not sure how likely this is as I know it makes things harder.

I was curious if in future versions if you would not rely on the Session state object, to accomplish roles it is not really needed as I can tell you know based off of how you are handling roles with the the forms authentication ticket method already.

We purchased the first version 1.0 of the KB and loved it. With most of our web based products we are forced by current usage levels and SLA's to deploy many load balanced servers for each of our applications. This creates state management issues, and eventually has led us to completely abandon any in memory or centralized session management schemes.

When we first installed your KB and realized that the only thing that really needed the session state was the admin an easy solution presented itself. We just disabled session state on the production copy and installed an admin only copy to administer the database.

When version 1.2 came out we were very pleased with the new features but we had to do a little work to get the application to not to rely on the session object.

This is a concern for us as you move towards version 2.0, because as you add more and more of the features that are on the list, the decisions you make about state management are going to affect how much of the product we have to tweek to enable us to use it in a highly available environment.

Keep up the good work, your product is nice.

Thanks

Adam Rogas
Load Ltd.
www.load.com

RE: Additional Security Features

Daniel Brewerton — Fri, 26 Sep 2003 16:10:00 GMT

Hi there Ryan. So far this KB is amazing. One thing that I'd like to see implemented is an author role so that my in-house users are allowed to add and modify articles but can not delete or make them public until the article is approved - Admin function. What is the likelyhood of you getting this into the next release?

A user role structure like this:

Web User - Anonymous
Employee
* View Only (What is there now)
* Author (Like to see added) Can create & modify
* Moderator - Create, Modify, Delete, Approve
Administrators

Does that help break it down a little better?

RE: Additional Security Features

Ryan Healey — Sun, 18 May 2003 08:29:00 GMT

Hi,

I'm not able to offer a specific release date for v2.0 of InstantKB.NET. I can assure users this will be available within Q3 this year.

I'm currently busy working on v2.0 of InstantGallery.NET. Once this is released further development on InstantKB.NET will be top priority. This may involve a number of minor releases before we reach v2.0. I will have to see how the enhancements pan out.

Existing users of InstantKB.NET will receive the upgrade to v2.0 free of charge. I'm planning to revise our upgrade policy for this product once we reach version 2.0.

I hope this answers your questions. Please don't hesitate to reply to this post or contact support@instantasp.co.uk if you have any further questions

RE: Additional Security Features

Wondrouz — Sat, 17 May 2003 05:24:00 GMT

Any date for the v2 release?

Current version is it upgradable FOC to the new version?

RE: Additional Security Features

Ryan Healey — Tue, 13 May 2003 07:48:00 GMT

Hi Tom,

Some great suggestions there - I've answered each question below. If you have any further questions please don't hesitate to post a reply or contact me on support@instantasp.co.uk

1. I plan to add the ability for users to login in v2. You will have the ability to create categories and assign an access level to the category. Based on the members privileges only specific categories will be displayed. This has been the most requested feature since the kb release.

2. Yep Internal Only documents and categories will be available within v2.0.

3. This is a great suggestion. I will certainly look into this idea. The attachments would be quite easy to do this with. The external links and related articles maybe a little tricky. I'll look into the possibility for v2.0.

4. I plan to improve the current work flow for the kb articles. I'm not 100% sure what you mean by have a section for ? - Maybe we could chat on MSN once i'm close to adding this feature. I'd be more than happy to discuss and add this feature if required.

5. Good suggestion - i'll add this to v2.0.

6. Oh my god - these suggestions are getting better - Again i will certainly look into this for a future release. I'll add all your items to my wish list. Great idea.

7. This could be an optional feature. If this is not within v2, i'll certainly add this in a release at some point

8. I'll look into this possibility. What problems is it causing at the moment running within a https:// space. Have you tested this ?

9.You could change this from within the web.config. However i may move all configuration information into a database with v2.0.

10. This would be quite easy to do. I plan to great groupings for KB members, this would allow you to globally set permissions or remove access per group or per user. This should allow you to do this.

11. I've already looked at integrating the two applications. I plan to get them both working with each other for v3

I hope that has answered your questions. If you have any further queries please don't hesitate to contact me. I'm more than happy to help.

Additional Security Features

Tom Grumbling — Tue, 13 May 2003 07:27:00 GMT

Could you layout the security design plans you have for V2?

I would like to be able to:

1. Vary security by knowledgebase and by categories/folders below the knowledgebase.

2. To declare an article as internal only.

3. To have internal/external designations on parts of an article. Notes, links, attachments could be internal only or Public and would display appropriately to the person viewing the article. This ability to have linked internal information is vital.

4. To have a section for Publisher / Editor / Review / Approval notes that would only be available to those with appropriate editting or workflow rights.

5. To have a section for mynotes or mycomments which I can attach and be the sole viewer of that info.

6. To have publication dates (Start and End) on articles with the ability to search unreleased or expired articles for those individuals with the approriate rights.

7. To have required user account password changes occur on a scheduled basis.

8. To support https: 128 bit encryption minimally to maintain information security to the browser.

9. Selectable timeout for inactivity

10. Security allowed based on an organization/employer affiliation. eg. if I open my knowledgebase up to my customers and one of my customers discontinues it relationship with us, I want to term or PEND all the associated subscribers to my knowledgebase(s)

11. I would like the security for forums to be shared or consistent with the knowledgebase, so maintenance is as minimal as possible.