Archived Forum

Hello Paul, on emoncms.org the read apikey is used for the app access, but yes once you share your readkey the user has read access to all the other read accessible api's such as

https://emoncms.org/feed/list.json?apikey=

The use of the read key for the app module wasnt really designed for dashboard sharing, more to provide easy personal access to the apps from a browser bookmark.

A solution might be to use the public/private feed designation in a similar way to how its done in the dashboards but doing this would need quite a bit of development I think. Perhaps a good thing to look at as the app module develops.

Hi Trystan, I hear what you're saying and agree. The read key is not intended to be a security feature, but as it is, with an account with no public feeds and no published dashboards, i.e. no exposed data even to those holding a read key. any and almost all feeds are accessible by clicking the myelectric settings button and picking any non-public feed to view. I consider this a huge hole in the security. Since I have nothing to hide, this isn't my concern. More that the ability to select feeds is available, causing confusion and then not being able to save those settings, is causing further confusion. It makes the web app look like it is faulty or unfinished.

If the button didn't work unless logged in, the issue would be resolved.

Paul

I see what your saying, i will hide the ability to change the settings.

I've sorted this in the new version of the app module, the configuration icon is hidden if the session is not a write session: https://openenergymonitor.org/emon/node/12502

Thanks Trystan, the "readkey" now functions as I would expect for viewing the MyElectric app only.

However using the read only apikey has some unexpected behavior. It exposes the dashboards menu but not the apps menu, it also shows the link bar as populated with the published dashboards, but any navigation just results in reaching the log-in screen.

Personally I would expect either all of the links to be hidden as per the readkey or for a better "readonly" session only the published links on the navbar to be seen without exposing the dashboard menu that in turn shows unpublished dasboard links and for all shown links to function "read-only" without logging in, I would also expect to see the apps menu to be able to switch between the apps without typing or using bookmarks.

Paul

I see what your saying, there's a problem here that if you use either the read or write apikey in the URL in this way any links that go off the page that then do not also contain the apikey's will not work - they will just return you to the login page.

But there is no current way within emoncms modules to distinguish between apikey authentication and session authentication as its abstracted earlier in the chain.

I could restrict the read apikey case so that at least in that instance the menu wouldn't show, but cant restrict the write authentication case as then the menu would not show if logged in normally - that is without introducing a session type property to the session object in emoncms..

Okay, I see how that works now.

IMO it would be better if non-functional stuff isn't shown in read-only mode, it's tidier and raises fewer questions from users who have a link to a single page. I can't think of any other time the read apikey is used for navigating other than within the url's of specific pages, if they cannot navigate to other read-only pages then there would seem no point showing the links.

If we want to make other pages available in read-only mode from the same url it is easily done by adding some hyperlinks containing the read apikey to navigate, it would be clearer to the user if there were no tempting but non-functional menu or navbar links to draw their attention. The hyperlinks read apikeys would then be naturally overridden during a logged in session.

Paul