Messages

31

Web Server - Ask For Help / Attacked by Let's Encrypt

« on: July 19, 2023, 03:17:49 PM »

At least I *think* it's ACME gone rogue.

I have an API/web server on an internal LAN.  It's been using a certificate from our local certificate authority that's trusted by Active Directory.

That certificate expires on August 19.

It appears that yesterday the ACME service helpfully decided that my certificate was too stale for its taste.  Couldn't get something from Let's Encrypt (since I'm on a LAN).  And decided to overwrite my still-good certificate with its own new rubbish certificate issued by sales@capesoft.com.
Well, it may be rubbish but at least it's good for a year!

Is there some way to pull the teeth on this?  I don't want to replace the legitimate cert until the beginning of August but don't want the server overwriting it each night.

TIA

Jane

32

Web Server - Ask For Help / Re: p_web.SetTheme('Metroblue') wont compile

« on: June 23, 2023, 03:39:40 PM »

Try
p_web.ChangeTheme

33

Web Server - Ask For Help / Re: Next freezes browse

« on: June 20, 2023, 06:00:26 PM »

I just had a similar thing happen, Ubaidullah, with a simple wizarded app using one TPS table.

After much hair pulling I found that completely clearing Chrome's history fixed the issue.  (I first tried uninstalling and reinstalling Chrome, but without marking the "clear history" checkbox, and that did not fix it.)

In my case I had discovered that other browsers were able to page through the browse successfully.  I presume you've tried other browsers and/or other client computers?

Cheers,

Jane

34

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: June 19, 2023, 12:23:17 PM »

Extraneous backslash error fixed in 12.62.

Alternate UPN suffix for login working in 12.62 LdapDemo app.  (Nice cleanup using equates for states in ValidateUser.)

Thanks, Bruce!  (And Sean)

Jane

35

Web Server - Ask For Help / SOLVED Re: 12.60 Header menu DIV mismatch

« on: May 23, 2023, 07:01:39 AM »

AHA!

It's the old "do what I mean not what I type" trick. 

You've got a typo, Bruce.  block should be p_block on line 11279. 
Fixing that fixes my issues.

36

Web Server - Ask For Help / Re: 12.60 Header menu DIV mismatch

« on: May 22, 2023, 08:10:35 PM »

I put in a couple of trace statements.
The 'nav' is correctly sent from the procedure, but the IF OMITTED in the class is considering it omitted and injecting the default DIV.

I don't have time tonight to re-install 12.59 again to compare.

 

37

Web Server - Ask For Help / Re: 12.60 Header menu DIV mismatch

« on: May 22, 2023, 07:36:18 PM »

Hmmm...  I don't see where this is happening but think this is probably my issue.

12.60 has changed the double drop menu to be a DIV (versus the NAV in 12.59 and earlier) but the closing tag is still for /nav.

38

Web Server - Ask For Help / 12.60 Header menu DIV mismatch

« on: May 22, 2023, 06:58:06 PM »

From the history:  "Fix: Better handling of blank parameters in SetDomains, CreateButton, _DivHeader, _DivFooter"

Is that what I'm seeing?  I now have the border-bottom for the header appearing below the browse or whatever's on the page. 
And on the index page, the default vertical height is gone.

Are there some "blank parameters" somewhere I've forgotten to set?
(Default for app is Div Grid).

Thanks!

39

Web Server - Ask For Help / Re: DOCS:FileName needs to be changed to DOC::FileName ?

« on: May 19, 2023, 08:37:10 AM »

?? I just clicked on web40.app in a fresh install of 12.59 and it compiles without error.

Generated code for me is

Code: [Select]

      packet.append( p_web.CreateHyperLink(p_web._jsok(Left(p_web.FormatValue(DOC:Name,'@s20')),(Net:HtmlOk*0)+(Net:UnsafeHtmlOk*0)),'ServeDocument?name=' & DOC:FileName,'_blank',p_web.combine(p_web.site.style.BrowseHyperlinks,),loc:javascript,,0,(Net:HtmlOk*0)+(Net:UnsafeHtmlOk*0),,,'DocumentsBrowse'))
If you go into the browse properties, click on the DOC:Name field, then on the OnClick tab, is it entered incorrectly in the URL field?

40

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 11, 2023, 09:17:43 PM »

Didn't receive anything, Sean.  Just sent you a PM through this forum.

41

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 11, 2023, 12:30:20 PM »

Thanks again, Sean.

I've been going through several possibilities:
1.  Just create my own derived methods in all apps
2.  Edit NetLDAP for my own use since it rarely changes
3.  See whether I can persuade Bruce to incorporate my NetLDAP changes, assuming they don't break anyone else's code. 

To explore the latter possibility, could you email me an address I could use to send my revisions for testing... to see whether they break your stuff?  I don't know whether Bruce would be OK with my posting his entire NetLDAP.clw file in a zip file on a public site like this.

Thanks,

Jane

42

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 09, 2023, 01:59:11 PM »

Pre-fiddling is good, Sean.  Sometimes very good

How much of the NetLdap code is you, Bruce, someone else?

Fortunately, all the methods are virtual so it's easy to override them in procedures.  I would find it useful to have one additional string added to LDAPParametersGroupType ( a string(500) for distinguished name) but can live without it.

But is it you or Bruce who vets this code?

I've got code now that so far seems to deal with the various permutations of the different-domain-UPN without breaking same-domain-UPN or plain name or domain\name formats.
My overrides are 
1.  NetLDAP.SetDomain  (still need to work on making this more generic)
2.  NetLDAP.SetUser (ditto)
3.  NetLDAP.SetAuthUser - I think this is now a generic replacement for the shipping procedure.

I'll post my stuff when I've massaged it a bit more - probably in a couple of days.

Again, thanks for the input.

Cheers,

Jane

43

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 08, 2023, 09:01:03 AM »

IF NOT INSTRING('\',parms.pAuthUser) AND NOT INSTRING('@',parms.pAuthUser)
            parms.pAuthUser = CLIP(Config:Logon:Domain) & '\' & parms.pAuthUser
END

Now that's very old and may not be needed as such anymore, but it works, so I'm not touching it!

Where are you finding that code, Sean?
That is fine and solid - assuming that the Active Directory forest only has one domain (Config:Logon:Domain).  Which is the case with my client.
That's similar to line 592 in NetLDAP.SetAuthUser. 

The code that has changed - removing self.LoginDomain but leaving the extraneous backslash, is in NetLDAP.SetUser (not SetAuthUser).

The LdapDemo app checks group membership for pUser, not pAuthUser.  NetLDAP.UserInGroup uses self.user, not selfAuthUser.

My new situation may seem strange, but may become more common. 
The AD domain uses a .LOCAL suffix.  The client needs to switch user logins to an actual owned domain for some kind of AD-integrated cloud-based single-sign-on service for compatibility with third-party cloud-based apps.

I have figured out how to make this domain mismatch work in my situation.  (Multiple possibilities, listed below.)

But I don't want to code it that way if it might be better to fix NetLDAP.clw.  (In case this client is not the only one for whom the mixed-domain-name situation will ever show up).

Illustration:
In the first pic, I've set up my domain to support two  UPNs in addition to the domain default (which is beach.test).

The second pic shows running an attributes query in the LdapDemo app for Suzi@janefleming.com who is actually a user in the beach.test domain.

Third pic shows the UserInGroup call from the LdapDemo app.  On the first pass through, it correctly has the beach.test AD domain name.
But in order to fetch the distinguished name it resets self.domain by fetching the (bogus/arbitrary) domain suffix from the user being checked.

In the second part of the recursion, it uses that incorrect dc=janefleming,dc=com in the call to Active Directory and throws an error.  (Third pic).

I have multiple ways to fix it that work for me.
1.  Override NetLDAP.SetDomain so it returns based on Config:Logon:Domain.
2.  Make my own call to search attributes for the distinguished name BEFORE doing the InGroup.  That avoids the recursion which avoids the wrong domain name being set in NetLdap.SetDomain.
       This second choice also has some slight speed improvements in one of my apps that checks 5 different group memberships as part of the login.  I can code so I only need to look up the distinguished name once and use that for all 5 domain-membership lookups. 

Again, don't know whether anyone wants to modify NetLDAP for this.  I'm fine coding my own workarounds now that I understand the issue.

But the extraneous backslash in NetLDAP.SetUser is definitely a bug that isn't valid for anybody's situation, as far as I can tell.

Cheers,

Jane

44

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 07, 2023, 09:31:49 AM »

I'll have to digest the rest tomorrow

Sorry for the long rant, Sean.

TL;DR

I think your client situation sounds like
sAMAccountName = jane
windows2000 = myAdDomain\jane
UPN = jfleming@myAdDomain.local  (Same domain, different user name)

whereas my new situation is
sAMAccountName = jane
windows2000 = myAdDomain\jane
UPN = jane@myEmailDomain.com  (Different domain that does not match an actual AD domain, same user name)

Yep, I will confirm you're the lucky one.

Yes, I'm truly special 

Cheers,

Jane

45

Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure

« on: May 06, 2023, 04:53:55 PM »

Thanks for confirming, Sean.

Up until now, all our UPNs have been default - matching the Active Directory domain name.

We're confronting needing to change our AD logins to jane@theEmailDomain.com rather than jane@theADdomain.local for some kind of integrated SSO security system our IT is looking at adopting.

I've changed my UPN to the proposed domain name (jane@theEmailDomain.com) and done some experimenting.
On an existing NetTalk app, I was not able to log in and get group membership when using
jane
theADdomain\jane
jane@theEmailDomain.com

Problems I found:
1.  The backslash issue.  Thanks for confirming that that's not intended.  That was making theADdomain\jane fail.
2.  Login default -
   NetLDAP.Start sets self.DomainType = NetLDAP:UserPrincipalName
   So for a login that I (and most of our users) typically do with just the sAMAccountName
      jane
   NetLDAP.SetUser uses self.DomainType , which means I have become jane@theADdomain.local (rather than the correct UPN that is set in AD).
   NetLDAP.SetAuthUser ignores selfDomainType and hard codes it to NetLDAP:UserPrincipalName (i.e., jane@theADdomain.local)
   
   In the 20+ years I've worked on AD networks I haven't been part of one where the UPN didn't match the AD domain name until now.  (Lucky me.)
   What I've discovered about UPNs is
      a. The UPN specified for the user is primary.  (In my case, jane@theEmailDomain.com )
      b. BUT the default UPN (jane@theADdomain.local)
         WILL also work for user login
         WILL NOT work to look up group memberships or attributes
      c. So having NetLDAP set the UPN to jane@theADdomain.local for a simple 'jane' login bolloxes things.
         Basic login works because of the implicit UPN
         Group lookups do not work.
         
   For the plain 'jane' login I can compensate by putting
       net.domainType = NetLDAP:sAMAccountName
   before calling net.UserInGroup()

   (I think this problem of defaulting to NetLDAP:UserPrincipalName is actually my doing.  In discussing with Bruce years ago the various login names users can enter I think I suggested defaulting to creating a UPN.  Shame on me... sigh...)
   
3. NetLDAP.Search is out to get me.  (Actually, UserInGroup when pActiveDirectory is set to TRUE)
   The ActiveDirectory_UserInGroup procedure in the LDAP demo calls net.SetDomain()
   So when I use jane@theEmailDomain.com, net.SetDomain helpfully splits that into dc=theEmailDomain,dc=com
   This domain does not exist in Active Directory.

   If pActiveDirectory is TRUE, then what is produced from NetLDAP.UserInGroup() is
   pFilter=(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN=Jane Fleming,OU=SysAdmin Users,OU=CHC SysAdmin,DC=theAdDomain,DC=local))  -- which is correct.

   BUT the pBase parm fed into NetLDAP.Search is dc=theEmailDomain,dc=com
      WHICH IS WRONG because that domain does not exist in AD.

   If I manually look up the DistinguishedName and set that before calling net.UserInGroup(), then the recursive call (which sets the incorrect domain name) doesn't happen and I'm good.
   
So I think I can code around all my issues in my calling procedures (except for the extraneous backslash - which I edited in NetLDAP.clw.)  I made a dedicated proc to get the DN before calling UserInGroup.
Or I might try just overriding NetLDAP.SetDomain so that it always uses the domain being used by AuthUser.

And I'm guessing that not a lot of people will be using a different UPN suffix in Active Directory situations.  But perhaps good to be aware of the challenges in case anybody else goes that route.

Thanks for your input, Sean!

Cheers,

Jane