I am attempting to create a functionality where users without an account in my app can still see what has been sent to them via a link to an in-app screen.
Unfortunately, what happens is that the app opens the home page screen when I attempt to open the generated link in a new incognito browser session, instead of showing me that same screen I show to the content author when I offer them the option to copy the link to their now published content (they fill out a form, after hitting ‘submit’ the data populates a designated table, which I have verified does work - I can see the data in the table after the ‘submit’ button is pressed).
(Imagine you receive a link that has a personalized piece of information written just for you by someone you know, and you can see this information by opening the link even without registration in the app. But, if you then want to interact with this information - likes/dislikes/comments and such - you have to sign up).
Please help, the Glide AI is not helpful at all when it comes to this, and I am hesitant to upgrade to a paid tier because I don’t think there are more extensive access permissions with a paid tier - if this functionality doesn’t work in the free tier, I don’t want to waste money on something that won’t work anyway.
Hello @Ruslan_Raspopov 
How are your access settings configured in Settings > Access ?
Also, is your app published yet? 
Yes, I have published the app (otherwise I would not have seen the home page when I opened the generated link)
Access is set to ‘Optional user profile’
I have identified a sort of an issue with the way the table generates the link using the Template function, versus what the deep link to the screen I need to lead to ends up looking like if I manually copy it
*dl/7f803e/s/c2df92/r/b8-qIx-TRw-IsxT2qHUGJA
*dl/item/b8-qIx-TRw-IsxT2qHUGJA
The first code is the one that ends up actually opening the page I want to share, while the second one is what is generated in the table via the formula - meaning that it is no use for me to generate those share in the table to being with, because they are not going to be valid for navigation purposes.
so I have adjusted the URL template used in my table to include the screen/item numerical, and now the link actually works.
BUT! There are still two problems with this approach:
-
The user can see the navigation ‘back’ to the source collection containing the content piece, which for unregistered users should not be possible (according to how I need it to function).
-
Because the said collection is part of the menu, unregistered users can essentially view all pieces of content that were written for others - this isn’t how I want it to function, because the said content pieces should ONLY be visible if the user accessed them via a URL, otherwise you shouldn’t be able to ‘navigate’ to them.
Thanks for the explanation, it’s more logic to me now 
As long as this is the page you wanna share, you could easily recreate the real deep link using a Replace all column with this set up:
Appied to your values, you’ll get:
For a more advanced answer, here is a link to a Robert Petitto’s video. It explains the meaning of URL parts, such as s for screen, r for row and so on.
Technicaly, the deep link created is holding information from where the screen is opened (which screen), especialy useful for breadcrumbs for instance:
Hope it helps
EDIT: I haven’t seen your answer before clicking on Reply. This is still valid but not answering the last message though 
1 Like
I appreciate your input! I have reviewed Robert’s video, which led me to this observation about the link structure difference.
I am now on the final leg of amending the navigation issue, and thus having a shareable version of the app I am building.
Thank you!
Hm, how do I actually remove that breadcrumb/navigation button, so that it does not allow unregistered users to go back to the source collection of the content? Any ideas?
The breadcrumb is just a component, but you will still be up against a back arrow that’s especially apparent on mobile devices. In any case, maybe you can do something with CSS, which is still only cosmetic at the end of the day and can be easily overridden.
It should also be noted that any data not protected by authentication and/or row owners can be accessible by anyone with enough knowledge to know what they are doing. You may be sharing a link with no way to navigate to other parts of the app, but ALL unprotected data is still downloaded to the user’s device. Just be careful if your data contains PII.
Acknowledged. It’s a shame that this damn arrow cannot be removed.
And no, the data does not contain any PII, as the content is sent essentially without a ‘connection’ - only once someone signs up/signs in, and thus views the content from their user profile, will that piece of content become ‘proprietary’ to that user, and thus no longer available in the public domain.
It’s sort of like a key hidden somewhere in a public bush - unless you REALLY know where to look for it, there’s very little chance you will find it. And even if you do manage to find it, there’s probably very little value for you in it, because you have no idea what the key is supposed to open.
1 Like
I am afraid I am not that proficient of a user to be editing website CSS
I understand it may sound trivial, but there’s a reason why I am building on Glide - I do have a clear vision of what I want the user to see, but I am unable to work with code directly to make that happen. So I’m reliant on the components and logic provided by Glide for that
Rather than removing the back button (which personally I think is a bad idea), I think a better approach would be to set it up in such a way that there is nothing to go back to.
You could do this as follows:
- Create a Single Row table, and make this the source of a tab that is the only tab visible to non-registered users.
- Add a “Get Part of URL” column. Configure it to take the
id parameter from the Link to the Current screen.
- Publish your App, open it as a non-registered user, and capture the URL of the screen that sits on your single row table.
- Now construct a URL, appending an
id parameter on the end, where id is the RowID of the row in the other table that you want to expose. So you should wind up with something that looks like the following: https://my.glide.page/dl/dcc150?id=SPg1jOB8QVmnvqsU0L1P5w (This is the URL pattern that you will give to non-registered users).
- In the single row table, create a single relation column that matches the extracted RowID with the RowID in the other table (where your content is).
- Add a number of lookup columns that fetch the values you need via the single relation
- Display these on the screen.
Using the above approach, you should find that there will be no back button displayed on mobile, because it is a top level screen, and hence there is nothing to go back to.
I have tested this solution, and it works as described. Please note however, that it will only work in the published App. It will not work in the builder.
Also note that the caveat that Jeff Hager pointed out about data security still applies.
4 Likes
