NTWS and Desktop application using same SQL Secwin tables

[mtabakin]

I have an existing desktop application that connects to an SQL database on a cloud server. This application uses Secwin for login security. The following tables already exist in the DQL database:
      dbo.dbosecwin_access
                              _counters
                              _license4
                              _namescodes
                              _operators
                              _operatorusergroups
                              _querytable

I will be developing a NTWS application to access the same SQL database and want to use Secwin in the login similar to the NTWS Secwin example. The NTWS login will be using the "Self User Insertion" for initial login with a Captcha if they do not already have an existing Secwin login from the desktop application. Initially the self user insertion users will have very limited access until "vetted" after which they will be assigned to the correct "user group" for access.

1. My question is will I run into any trouble using the Secwin tables for both applications?
2. I assume I can follow the steps in the Jumpstart: Adding Runtime Access control to al NTWS application and just skip the step of importing the Secwin tables. Is this correct?
3. Also would I use the same Unique Application Name in the Secwin Global template since I want to access the same set of user credentials?
4. Since the NTWS would be running on the same cloud server as the SQL database I don't see any connections issues once the NTWS application makes the SQL DB connection and assume the NTWS can keep the sessions separate from one another.

BTW this will be NT 7.06 (or 7.07 when it becomes available).
 
Any other issues I need to address?   

[Bruce]

1. No

2. Yes

3. Hmm. At first glance it seems like a good idea to do this, but in our experience it causes problems later on - especially as your web interface and web interface diverge (which they will do because they're probably serving different people.) It becomes either a confusing interface (referring to controls which don't exist) or you have to work too hard to keep things in perfect sync. So while it can work, by recommendation here is to say No, use a different Area and manage the security for the web users, and windows users separately. (This sounds like more work, but isn't really because the users for the interfaces tend to be different.)

4. yes.

cheers
Bruce

[mtabakin]

Thanks Bruce. I see your point about using the same Unique Application Name for both applications. I "think" I remember there's a way or method to copy users from one Secwin application to another so I could at least "pre-load" the new NTWS application with the users from the Desktop Secwin logins OR are am I mistaken? The Desktop Secwin users have already gone through the approval process and have defined access levels, it would be nice to carry these over and just let the new users self identify and go through approval. Possible/easy?

[Bruce]

Hi Mike,

the users are definitely available - although they will default to no-access for the new area. That's not so hard to change by hand
by a supervisor and the Operators list, (or with a few lines of hand-code) if you like.

One of the things we discovered with "auto giving existing users access" was that it seemed like a good idea to save time when the web bit was first introduced, but as the people using the windows and web parts started differing it because unwelcome. Indeed the very idea that Windows users had automatic web access, and vice versa, became a hindrance not a help. (so we changed.) It's very "hard" to change an area name though because obviously existing clients have access set up on the old area name. So it's something that's worth thinking about up front - it's a lot easier to get it right now than it is to change it later on.

Unfortunately hindsight will likely prove you wrong which ever approach you take. There are benefits, and disadvantages both ways, so inevitably at some point you'll think "hmm, if only I'd gone the other way". On balance I'd use different area names if only because it's more secure. And ultimately that's a good goal to aim for.

cheers
Bruce

[mtabakin]

Bruce

Thanks for all the insight. I thought I understood your initial response about being able to use the same SQL Secwin tables for both the EXISTING desktop app and the NEW NTWS app (see original post on 3/19/2013). After some issues with getting the Secwin procedures into the NTWS app and compile issues because of corrupted imports I got the NTWS app sort of running. BUT here's the issue. It doesn't seem to be using the SQL Secwin tables. I'm confused.

If I look at the SQL Database I see the Secwin tables (dbo.dbosecwin_operators, etc.) but I don't see them in my Clarion dictionary used by BOTH the desktop application and NTWS app. Or do I see these tables referenced in code in the desktop application in the Secwin procedures used for login, browsing users, updating users, etc.. But the original desktop application is clearly using these tables as I can open the dbosecwin_operators table for example and see the users that have been added. So when I tried to make the NTWS secwin procedures reference the SQL Secwin tables I don't know how to do this. I did a test with importing the Secwin tables txd into the dictionary using the NTWS Secwin JumpStart instructions but these are either memory tables OR tps tables and are separate (?) from the SQL Database Secwin tables.

So here's this issues/questions:

1. How is it that the desktop application is definitely using the SQL Secwin tables for user control without entries in my dictionary?
2. How do I get the NTWS Secwin procedures to reference the very same tables used by the desktop application but with a separate application area as you've pointed out would be a good idea. The only thing I can think of is to import (synchronize) the SQL Secwin tables with my dictionary in order to get the definitions actually into the dictionary and then I can set the NTWS Secwin procedures to these tables?? I don't want to try this and screw up the existing desktop application unless this is the right way to proceed. I'm probably missing the "forest" for the "trees" so to speak but it seems I've just been going around in circles for the past few days. I also know the NTWS is connecting to the SQL database using the FM3 SQLConnect procedure as I can browse one of the tables that the NTWS is "serving" out so access to the Secwin SQL tables is there, just not in a way I can reference them. Don't know if his makes sense and as I said I'm probably missing some minor point that once resolved will allow everything to work properly. Thanks again.

[Bruce]

Mike,

Geoff is away this week, and this is probably one for him to answer.

Cheers
Bruce