In the ParseJS docs, you use Parse.User.signUp() to create a new user, instead of user.save() like other objects. The Parse server will encrypt the password, check user/email doesn't exist etc. before creating the user ... which is all fine.
But when the response is returned the JS client 'becomes' the new user. This is fine when someone is signing themselves up ... but when an administrator of a multi-user app is creating multiple users to access their account, this logic doesn't work.
// admin/users/add
- logged in admin creates a new user w/ create()
async create () {
const response = await Parse.User.signUp()
//- response is the new user ... but oh dear - the admin who was adding a new user has magically BECOME the new user as well!
}
I haven't seen such a thing in the docs but is there perhaps known (or undocumented) way to prevent the user who is creating new users from becoming the new user(s)?
It turns out after some discussion with a core team member that no, this is not possible.
The best alternative for me was to create a cloud function which ran the Parse.User.signUp(...)
Related
I'm updating a custom TYPO3 plugin from TYPO3 v10 to v11.
When a new user arrives, a record is set in the fe_sessions table, so clearly a new session is being created. In TYPO3 v10, even if the user us not logged in, I could access that session id via:
$sessionId = $GLOBALS['TSFE']->fe_user->user['ses_id'];
Does anyone have any suggestions as to how to do this in v11 please? I've not found anything in the documentation or web searches that quite fits the bill. The TYPO3\CMS\Core\Session\UserSessionManager looks promising, but you need to create a new userSession object with the userSessionManager to be able to access the sessionId. However all of the userSessionManager methods bar one to create the UserSession object require the session id as a parameter (circular trap). The only method that doesn't ask for a sessionId create a new anonymous session, which doesn't match the id in the fe_sessions table.
And since I want to access the sessionId on one page and re-access it on another as part of security check, any method that creates a new sessionId in order to view it won't work.
What am I missing? Many thanks in advance.
The user information has been moved in TYPO3 v11 to the context and can be accessed with $context->getPropertyFromAspect('frontend.user', '...');
see the manual
Sessions have an own UserSessionMangager and API
I'm using Supabase for auth, and I want to set a user as logged-in using my custom logic. I'm looking for something like the following:
if (logic-that-checks-if-user-performed-authentication-criteria) {
supabase.auth.setUserAsLoggedIn({email: "user#email.com"});
}
Is there some way I can do this?
Clarification:
logic-that-checks-if-user-performed-authentication-criteria would be my own custom authentication criteria, not Supabase's.
More context:
I want to add Twitter OAuth2 support as Supabase doesn't support it by default. I want to have my own API routes for handling Twitter OAuth2, and the related credentials would be stored either as user_metadata in Supabase's auth table or in my custom user table.
The user would be required to sign up with email-with-magic-link (usual Supabase code). But once they have signed up, they would have an option to connect their Twitter account (my code).
After they have connected their Twitter, they would be given an option to sign in with Twitter alongside the usual email-with-magic-link method. This part would require my original question, I would need to set the user as logged-in after I verify that the user has logged in with Twitter and the Twitter profile matches with the one I have saved in my DB.
As far as Supabase is concerned, a user is signed in if they are signed in with magic link.
It sounds like what you want to know is whether a user has gone through the Twitter OAuth flow or not. In that case, user metadata might be a good place to store that information.
Once a user goes through the Twitter OAuth flow, you could call the following code to store the fact that the user has gone through Twitter's OAuth flow.
const { data, error } = await supabase.auth.updateUser({
data: { hasLinkedTwitter: true }
})
You would be able to retrieve this information from the User object like this:
const { data, error } = await supabase.auth.getUser();
data.user?.user_metadata.hasLinkedTwitter
I'm trying to create calendars and share them with my organization's users using a service account.
What I would like to obtain is the ability to manage the created calendars both from my website code (using the service account) and from the regular google calendar web interface.
So i thought I could create a dumb user account (with credentials), impersonate it with a service account and then create and share my calendars and manage events both from my weba pp code and google regular user interface.
Is it the right way to proceed? Am I missing something?
If my last guess is right how can I achieve it using laravel and google-api-clients for PHP?
Thank you for your advices
After Sleeping on it I realized there's no need to impersonate a user and insert a new calendar.
To manage a service account calendar from the officiale web interface you can simply share it with owner rights to the "dumb user"
With something like this:
//create calendar
$calendar = new Google_Service_Calendar_Calendar();
$calendar->setSummary('calendarname');
$calendar->setTimeZone('Europe/Berlin');
$service = new Google_Service_Calendar();
$createdCalendar = $service->calendars->insert($calendar);
//share it with your dumb user
$rule = new Google_Service_Calendar_AclRule();
$scope = new Google_Service_Calendar_AclRuleScope();
$scope->setType("user");
$scope->setValue('dumbuser#organization.com');
$rule->setScope($scope);
$rule->setRole("owner");
$createdRule = $service->acl->insert(createdCalendar->getId(), $rule);
So my problem is solved for the moment, the only question I'm still thinking about is how can I impersonate a user with service account credential? Well I'll think about it when it will be really useful
Is it possible to disable requests sent to Parse without a master key? I'd like to only access Parse through my custom backend and not give users direct access. Does public 'read' set on the User class mean that anyone can read the records in that class? If so, why is this a default - wouldn't that be against good security practices?
Thanks,
Daniel
Public read means that anyone with your api key can read the user collection from your parse server. Api key is not the best approach to protect your app because anybody can know it by putting "sniffing" your network requests.
In order to protect and provide access you can protect your objects with ACL's which allows you to create access for specific user (who is logged in) or to specific role. So you have couple of options:
Create a master user - each user must have username and password and when you create your parse objects make sure that only this specific user create/read/delete and update them. You must only to make sure that when you create an object you create ACL for this user so only this user will be able to modify and read the object. You can read more about parse-server security and ACL's in here: http://docs.parseplatform.org/rest/guide/#security
Using parse cloud code - In cloud code there is a nice feature of useMasterKey which provide full access to any object of parse-server so for each operation that you run (via JS SDK) you can also set the useMasterKey to true and then parse-server will ignore all the ACL's and will execute the query for you. The useMasterKey feature work only in cloud code context so it's safe. If you want to provide additional level of security you can run the cloud code function with your master user (from section 1) and check inside the cloud code for the user session so if the session is empty then you can return an error.
You can read more about cloud code in here: http://docs.parseplatform.org/cloudcode/guide/
This is the code which validate the user session:
if (!request.user || !request.user.get("sessionToken")) {
response.error("only logged in users are allowed to use this service");
return;
}
I am currently writing a background job that deletes a (for inappropriate content, or violation of the license agreement) flagged user and all his content.
The problem is that if the user doesn’t logout manually, he can still use the app (and even create new content) even if his account does not exist anymore.
So is there a way to logout a specific user via cloud code or destroy his session?
Content creation in your Parse app isn't limited to a logged in and valid user by default, Parse does not know that you might want to limit content creation to valid and logged in users or not, some developers might even not use user accounts at all etc.
It is up to you to ensure that the client/user making the request is allowed to do so. This can either be enforced by using an ACL on your classes or by using a beforeSave function in Cloud Code. I prefer Cloud Code and it is pretty straight forward to enforce a valid user there.
Parse.Cloud.beforeSave("YourClass", function(request,response) {
if (request.user == null) {
response.error();
} else {
response.success();
}
});