Other SOTA sites: SOTAwatch | SOTA Home | Database | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA

SMP new version - Part II

So, the previous thread has been closed out after reaching 100 posts.

Continue the discussion here…

1 Like

i tried

i have just one browser-tab open using firefox 64 … tried with google chrome and there i stay logged in on the SMP-page! so it seems to be a problem with firefox browser, maybe one of my addons (noscript, ghostery, …) causes the problem? i will try to find what’s causing this problem

Martin, the lesson here is clear: SMP :innocent::innocent::innocent: good, addons :japanese_ogre::japanese_ogre::japanese_ogre: bad!

Rob :rofl:

noscript is almost certainly going to be a problem given the nature of OAuth2/OIDC

deactivated all of my installed addons, but the problem still exists …

OK, it looks like you may not be giving each newly-loaded page sufficient time to get the login details?

Each time a new page loads, the integrated SSO software has to check back with the SSO server to see whether the user is logged in - this can sometimes take a few seconds. You can see this process happening in the browser address bar. Try giving each page a little while to fully load and don’t click on the Login button…

switching to PM … don’t want to annoy all the readers with my little problem :slight_smile:

I have the same issue with Firefox + Ghostery, noscript and uBlock origin. Telling noscript to allow all scripts and disabling uBlock and Ghostery, I still can only stay logged in for 2 minutes. At present I’m using IE 11 on Windows from SMP and that stays in fine, so this is not a showstopper. I knew that Rob would be busy fixing proper bugs and haven’t bothered him with this. But if a solution is spotted, I’m all ears !

1 Like

Well, I’m also using Firefox latest version, but crucially, I’m using none of these addons. Don’t see the need for 'em!

This will be one of the reasons why I’m not getting these problems using any of the vast array of up to three browsers here. :sunglasses:

thanks to the fabulous “real-time-support” by rob i found what caused the problem. for some reason beyond my knowledge i had third party cookies blocked on my firefox browser … changed it and now it works like it should!

thanks again rob for your help,

73 martin, oe5reo

1 Like

That explains why the new DB was fine but SMP wasn’t. Some third party cookies allowed and we’re in business. Now I don’t need to use IE11, which is nice.

I wouldn’t even use IE11 to prop up a short table leg…:laughing:

3 Likes

So, the promised (@OE5YYN) new dialog window in the chases page is now operational.

Click on the “Set QTH…” button below the QSOs list area to show the dialog - here, the user can enter the following:

  • first name or handle
  • QTH latitude
  • QTH longitude
  • QTH locator.

Lat/long/locator values can also be set by clicking on the QTH in the map.

Enjoy!
Rob

Perfect! Thanks a lot!
Sylvia

Hi Martin,
Isn’t the definition of “third party cookies”, cookies coming from a different website than you are logged into? If so it would make sense IMHO to block them!

73 Ed.

grafik

there are two available options in firefox settings … switching from “all third party cookies” to “trackers only” solved the problem for me.

In order for SSO in the various SOTA sites, and in the SMP, to function, it uses its’ own cookies to track logins.

So, even though the user is “in” a SMP page, or a SOTA site page (the “primary page”), the SSO server (“third-party”) also needs to set a cookie in order to do its’ job. No SSO cookie = no SSO login.

i noticed that bug too … it seems not to pick out the S2S of the database after january 2018:


it say’s 30 qso’s and no s2s … but i made 9 s2s-qso’s that day, these are missing in the list and only 21 qso’s appear there!


this is the data on the sotadata-webpage for this activation.

rob, please add that to your to-do-list

spent the whole afternoon exploring all the new stuff on the new SMP-page! it’s just great … thank you!

73 martin, oe5reo

I thought that might be the case. I guess that’s one of the problems of implementing a single sign on across different servers. it’s a shame that the “cookie passing” couldn’t happen between the servers rather than via the user’s browser but I know this is out of the programmers control.

This is how mine is set:

I suppose if I wanted to make it stricter, I could add an exception for sota.org.uk

73 Ed.

Yes, we are aware of this. There appears to be an anomaly in the SMP copy of the SOTA db.

2 Likes