In my application I want to prompt a user about a new feature with some kind of a dialog the first time they visit the screen. And on a subsequent visit this dialog is not shown.
The obvious solution is to use a cookie or save this in the database.
But I'm concerned that:
- over time all the checks in the code will result in messy code
- with the database solution - it can bring performance issues.
And also if the user clears his cookies (for example) I don't want them to see every new feature update for the past two years (one screen can be have multiple new features over time).
Is there a stupid/simple way to handle this? How does twitter and facebook do this when they promote their new features?
My environment is MSSQL, ASP MVC if does matter.
Use both - cookies as a caching technique - first check the cookie. If it doesn't contain the flag - then ask the DB.
Also, you can initialize that cookie at login. One DB call per user session.
Personally, I'd use a database flag against the user record.
Like you say, cookies can be destroyed and lead to annoying duplicate reminders.
I don't think you need to worry about "messy code" if you're doing it right.
Since you have user login, I assume you also have some type of server-side session. You could store user preferences in the database, and cache them in the session upon login, avoiding going to the database for every request. As long as you trust your session for authentication purposes, you certainly can trust it for user preferences.
We store it in XML. Then you can use serialization to quickly save/load the settings. We store the XML in SQL (MS SQL have features that support XML)
Well the checks in the code are independant from the place you store the datas, it is a different problem.
As of your question I'ld say to use the database, for speed + ease reasons.
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
I have been following your project for quite some time now and am intrigued by the functionality of gunDB where it doesn't require a database in between and keeps security in check.
However, I've got some questions about GunDB which I've been thinking about for quite some time now before I can give Gun a go with a project I'm currently working on. In this project it is necessary that data is safe but should also be shareable once a group has been setup. The project is a mobile app project and ata is mostly stored on the device in a SQLite database.
I have been looking into Gun as it allows for better usage of the app in sense of collaboration. The questions I have, however, are:
User authentication
How is user authentication handled through private keys? So how can a user "register" with, for example, a username and password to login to the service.
For authentication I am currently using Firebase where it is possible to use username/password authentication and I would like to know how Gun approaches this case and how it's implemented.
Data storage
In the documentation and on the website it's stated that data is stored locally with every client and can be stored on a "node" or server using either a local hard drive or the Amazon S3 storage option.
What I am curious about is what data is actually stored at the client? Is this only the data he/she has access to or is this a copy of the whole dataset where the client can only access whatever he/she is granted to have access to?
Maintaining your data
When I've got a production system running with a lot of data, how will I be able to manage my data flows and/or help out my clients with issues they have in the system?
In other words, how can I make sure I can keep up with the system if I want to throw in an update and/or service my clients with data issues.
My main concern is the ability to synchronize their local storage correctly.
Those are all my questions for now.
Thank you very much in advance for providing some clarity on these subjects.
Best regards,
(Answered by Mark Nadal on Github: https://github.com/amark/gun/issues/398#issuecomment-320418285)
#sleever great to hear from you! Thanks for finally jumping into the discussion! :D
User Authentication,
this is currently in alpha. If you haven't already seen these links, check them out:
https://github.com/amark/gun/wiki/auth
http://gun.js.org/explainers/data/security.html
https://github.com/amark/gun/blob/master/sea.js#L23-L43
https://github.com/BrockAtkinson/login-riot-gun
If you have already, would love to either (A) get you to alpha test and help push things forward or (B) hear any specific questions you have about it. This thread is also a more at length discussion about alternative security API ideas: #321 .
Data storage.
Browser peers by default store the data that they subscribe to, not the full data set. You could ask it to store everything, but the browser wouldn't like that. Meanwhile NodeJS peers, especially if hooked up to S3 or others, would store all data and act as a backup.
Does this make data insecure? No, encryption should keep it secure, even if anybody/everybody stores it, the encryption makes it safe. (See [insert link to (1)] for more information).
Maintenance.
You would service your customers by deploying an update to your app code. It would not be ideal for your customers if you could meddle with their data directly. If they wanted you to do that, my recommendation would be that they change their password, give the new password to you, and you login and make any necessary changes. Why? Because if you have admin access to their data, their privacy is fundamentally violated.
In my Java web application,when a user gets logged in,i store the user name and other details in session as follows,
session.setAttribute("userName",username);
I am using ExtJs4 for UI.How to get the session variables in extJs?
Thanks
I can second #Geronimo approach. You need to get user Id and/or permissions when you authenticate the user. However...
You can't rely just on the username/permissions that you store somewhere in your JS code because it can't be easily spoofed. If you present user with some information that can be different for different levels of access you still need to do server side validation of the user identity.
You can't get session variables off the server web container using javascript only.
I do the same thing (storing userId as a session variable in java). I use Ext.Request to perform an Ajax request to a java servlet to get it (along with other data about the user like permission settings for the webapp to enable or disable features they wouldn't be able to use).
EDIT:
I second sha's answer also, the only reason I pass the authentication information back to the client is for cosmetic reasons - so that user doesn't think he can use a feature in javascript that would be denied by my server side authentication. If he were to spoof the userId or permissions and try to use the feature, the real authentication on the server side would stop him.
I understand that the question has been asked for a long time ago, but despite the large number of views and the absence of an plain answer, I decided to offer this answer:
Assume that the session variable is registered like /index.php?PHPSESSID=9ebca8bd62c830d3e79272b4f585ff8f
In this case, you can get the variable PHPSESSID through JS object "location" and transform it through Ext.Object.fromQueryString()
So:
console.log( Ext.Object.fromQueryString( location.search ) );
will prepare PHPSESSID variable for your needs.
I will like to know how does Stackoverflow maintain the additional details of users logging in using open-ids? In my knowledge, the details of these users are stored in the server of google,facebook etc. (The ones whose open id is being used). How then this site is also storing info about user's points, badges, privileges etc.?
Open id Selector, the one being used by Stackoverflow, is a client side javascript library so how is this possible?
Is a separate database created? If yes, how? There is no registration even!
Please provide the details of how this is being done.
When you login, the server checks if you already have an account. If there is no entry (it is the very first login), the server will automatically create a new user and save the openid identifier.
So the next time you login, the row is already there, and Stack Overflow will recognize you. By the way, you can learn the id of your database entry by looking at your profile url.
The JavaScript openid-selector is not involved in any of this. It just is a convenience feature which allows easy selection of an openid provider. All its magic is done before the openid magic takes place.
I heard in an old stackoverflow podcast that they minimized the use of sessions, and that they basically only needed it when posting. How can that be? Don't they need to use some form of sessions on every page view if nothing more than to tell that I'm logged in? How else do they show your username instead of the "Log In" prompt at the top of the screen?
When this type of thing becomes important is when you're persisting your sessions in a database. Now each time you touch your session store, you touch your database. So it would be great if you could avoid it.
You could store all your state in a cookie, but if you care at all about security, then you'll probably want to control state on your server instead.
I don't know about the podcast you're referring to, but I'm not really sure they were saying what you thought they were saying...
Session data doesn't necessarily have to be written to DB everytime it's touched. You could easily have a cached (using memcached or something similar) intermediary. You could then write the session data to DB every X amount of requests/minutes/writes/whatever.