NetTalk Central

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Jane

Pages: 1 2 [3] 4 5 ... 23
31
Web Server - Ask For Help / Re: Attacked by Let's Encrypt
« on: July 19, 2023, 06:44:14 PM »
I had had the word "something" in the CA Account entry field on the web server.

I've blanked that field to see whether that will inhibit the automatic cert-fetching.

32
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

33
Try
p_web.ChangeTheme

34
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

35
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

36
AHA!

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

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




37
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.

 

38
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.


39
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!



40
?? 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?


41
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.

42
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

43
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



44
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 08, 2023, 09:01:03 AM »
Quote
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

45
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 07, 2023, 09:31:49 AM »
Quote
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)

Quote
Yep, I will confirm you're the lucky one.
Yes, I'm truly special  ;D

Cheers,

Jane

Pages: 1 2 [3] 4 5 ... 23