I’m trying to use the Opening event of a page to challenge if Session.IsLoggedIn, and then direct to AnotherPage.Show(). Code doesn’t work in Opening, but does work in Shown. I’m hoping to not send anything to the users browser if it fails this test (isn’t the Opening event of a page the proper place to evaluate this?
If Session <> Nil Then
If Not Session.AdminLoggedIn Then
AdminLogin.Show()
End If
End ifyou can do that already in the session events.
Oh? Which Session Event is “prevent this page from being sent to the browser because the user isn’t authenticated” ?
I’m managing all of this via the session.opening event, not sure if that’s the best way though, but it works.
#if DebugBuild
// I'm the admin, show my page w/o logn
wpMain.show
// If I need to test the login, I uncomment this
'Var loginDialog as new wdLogin
'loginDialog.show
#else
if session.LoggedIn = false then
Var loginDialog as new wdLogin
loginDialog.show
else
wpMain.Show
end if
#endif
LoggedIn is a property I defined in session and I do set that in my own wdlogin dialog if the credentials were OK.
That’s not the same thing. One goal of the design OP and I are trying to achieve is to prevent a page from ever being sent to the browser by mistake. Yours is an auto-login.
Mistake, like “via mistake in your own code?” … I haven’t found a way out of that, as you have it for instance in different python frameworks, means it seems that xojo leaves it fully to the developer. Something like a webpage property for OnlyLoginWithCredentials would be nice.
Yes, I’m sure you’ve had those too.
It would be nicer if the framework didn’t fail to perform.
Sure, you are absolutely right :-). At least it seems that a webpage can’t be called directly via a certain URL, but here again I’m not sure and the non-existant documentation (at least I have not found anything) makes me feel unconformtable.
The first part is auto-login in debuggung, but the else manages that someone can only access with credentials. But this is for instance not enough if you want to steer your access rights more granularly per page. Means that an admin can see different things than a super user or a “normal” user. So far I’m steering this via separate pages per group, as again I don’t feel 100% secure.
yup, especially as there doesn’t seem to be a logic on what works in opening and what in shown :-(.
For good measure, here’s a Web 1.0 project indicating that this is a regression in behavior.
I agree, security has to be easy and taken seriously.
Can you confirm that a webpage is at least not accessible directly by some kind of URL, be it as cryptic as possible? I haven’t seen anything neither in the documentation nor the debugger, but this doesn’t say anything.
This is not a feature of either Xojo Web framework, nor the topic of this thread.
I think it is (at least partially). If the framework forbids any webpage / webdiaog access other than those managed via the code then you have to manage the respective access rights solely via the session and avoid that a webpage is even trying to fire the open or show event, just don’t open it from session. And if you want to open from your mainpage another page, you need to test again the permissions via your defined properties in session, before calling that new page.
The whole security topic is my disappointment with Web 2, even though I like it overall very much. When Geoff announced Web 2 long time ago, I remember he mentioned something about Logins being embedded. I thought about a default Login control and some basic default kind of permission-handling via the IDE.
In some python frameworks you can define for instance the routing as such that certain pages need rights for a certain group. The framework then checks if the logged in user has those rights - if not there ist 100% no way you will ever make it on that particular page even if your call tries to call that page for a user who doesn’t have the appropriate rights. Not sure if I’m explaining this correctly, think of it as a segregation between the security layer and your code.
I’m encouraged whenever I see such a thorough set of responses! The concept was that I’d use the Opening event in pages that are “off limits”, and for those users who should be able to access those pages they’d have to have had their session authorized. Using the Shown() is a bit too late as it immediately renders the content, then redacts it - but again that’s too late.
Naturally this means ensuring that any navigation tools, buttons, etc. contain logic for disabling a call to Show() secure pages.
In a perfect word the default page could load, a Session is born, and moving away from that page to an unauthorized page would force a security challenge. It’s okay if there is a better suggestion out there, and certainly if there is a better best-practices to be following.
I’m wondering if the issue here is a result of the framework preventing a race condition. It’s an interesting issue, and I’d open a Feedback Case about it. That said, to be entirely safe, you should validate the user’s login before attempting to send them to any secure pages rather than sending those pages, validating the user, then having your app realize they’re not allowed to access a resource and change to a different page.
That said, @Jeannot_Muller, you’re dragging this off-topic and confusing the issue when they’re trying to track down an event-related problem. Other security concerns, while they may be valid, don’t help @William_Reynolds solve his very specific problem.
Granted, sorry! - But I think that from the discussion we have the headline is just not precise enough, as from @William_Reynolds response I think he is exactly trying to solve what you and I described.
I still believe William is asking 2 related questions and it as such two-fold:
Sure, that’s clear. Though we don’t always work on our own code. It’s good to have fallback safety precautions. The fact that Web 1.0 could do this and Web 2.0 cannot means that it’s a regression in functionality.
I’m frankly quite tired of people trying to tell me what I want. I don’t want workarounds, I don’t want a discussion on best practices.
I want to discuss the bug at hand. I want a framework I can rely on.
Please, stick to your thread.
I agree with you. It should work. That’s why I suggested opening a Feedback Case. I can envision many scenarios where I may want to do the same.