Hang tight while we fetch the video data and transcripts. This only takes a moment.
Connecting to YouTube player…
Fetching transcript data…
We’ll display the transcript, summary, and all view options as soon as everything loads.
Next steps
Loading transcript tools…
René van Hofwegen, Project start 101 Workshop | Mendix Stream | YouTubeToText
YouTube Transcript: René van Hofwegen, Project start 101 Workshop
Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
Video Summary
Summary
Core Theme
This content emphasizes the critical importance of building secure Mendix applications from the ground up by implementing robust security practices and understanding the underlying business context.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
>> Yeah. But first, I want to have uh
uh
Am I live?
>> Yeah, you're live.
>> I'm live.
Cool. That's cool.
Yeah. Yeah. Here we are. Here we are. Tada.
Tada.
>> What?
>> Entire window.
>> Yeah, there it is. The entire window. Share.
>> Yes. >> Perfect.
>> Perfect.
>> We're on. All right. Am
Am
I audible at a remote location? Can you
hear me through the stream? [Music]
[Music]
Maybe you can confirm in the chat. >> Yes.
>> Yes.
>> Yes. All right.
>> It's a delay. Remember, when you ask question
question
>> Yeah. I have to be patient. >> Yeah.
>> Yeah.
>> Which is not my best trait, right? Okay.
Good afternoon. I hope you had all a
good lunch. I've seen the lunch here in
Rotterdam. It was good. I'm stuck. I
don't know
the lunch was in all the locations where
you are around the globe. Maybe you
already have had dinner. That's that's
also a possibility, right? Uh or maybe
you are using breakfast.
>> Yeah, breakfast. So, I hope you're all
feeling well in any form or shape.
Right. Welcome. I'm happy to have you
here in the workshop. Min project start
101. So let's start with the beginning
and um I need to move some small trick
otherwise my remote wouldn't work. Um
who am I? Uh who's this guy talking
here? Um when I uh did a little bit of
work of at Mandix did something with the
menics academy thought hey this is
something I can do outside. So I founded
the low code academy to even extend
whatever is done by the menis academy
and help yeah new manage developers
become awesome developers and I'm doing
that for around 15 years now. So, rookie
we're here to hack Manx app. And did I
told you, okay, if you use this
JavaScript and this console and that
bird and this that, you can hack many
applications or at least you can try to
hack many menx applications. But
But
we're also menx developers.
And Monday when you're back at work, you
should and of course yesterday you
should have done it as well. The goal is
to model secure apps from the ghost
time. So having applications which
cannot be hacked or at least as less as
possible and that's what I'm going to
talk about. Uh because your job as a
developer is to develop secure manage
applications, right?
Agree. Cool.
>> How sure are you that you're developing
secure apps on a grade from zero to 10?
>> Nobody dares to answer at this moment. I
will forgive you. That's something you
have to answer for yourself. Um,
Um,
first question to you. How to model a
secure app?
This is a very open question, very broad
question, but I'm open for a very broad
Nobody.
>> What's your approach? What are your
tools? Nothing. Yeah. leastrivilege
principle.
Well, that's directly an high-end answer.
answer.
Do you think it's always done like that?
Are you always sticking to that
principle? Sorry.
>> Obviously not.
>> Obviously not. That's an honest answer.
I think
someone else.
Let's Yeah,
>> start up your project. You enable your
security settings. >> Yeah,
>> so you do it on the pro demo so you can
>> For people watching, can you repeat
what's being said?
>> Yeah. Yeah. Yeah. Yeah. The the first
answer on my question was le lease
privilege and uh the second one was
Yeah. turning on your security from the
start while developing and I tried to
trick him by saying so you turn on
prototype demo and he said yes so I hope
we can correct that setting
>> two answers online as well. Yeah. If or
Yeah. Yeah.
>> So security with entity right access. >> Yeah.
>> Yeah.
>> And do the thing the guys mentioned in
the first session and encrypt all the things.
things.
>> One encrypt everything. Okay. But yeah,
if you encrypt it, you have to decrypt.
Okay. Challenging. And the other answer
was setting up with entity access
>> right access.
>> Read and write access. Yeah,
that's exactly how we do it. because
that's the first step in developing
manage app. >> Um,
>> Um, next.
next. >> Yeah.
>> Yeah.
Why do we have application security in
the first place?
I'm seeing that I'm using the old
slider. That's another story.
Why do we have application security in
the first place?
>> To protect data.
>> Protect data.
For whom?
against who?
>> Yeah. People who don't need to see.
>> People who do not need to see. People
who do not need to see. That's that's
that's a quite broad definition. I want
to narrow it down. So why do we have
For who are we implementing security?
Maybe that's an more specific question
for who? >> Sorry.
>> Sorry.
>> To protect the user.
Why do we need to protect the user
I think the reason why we do have
application security in the first place
is because we have people around who
should not do what they do
and that's exactly not the user
because if it was all about the user
um the normal user will use the
application as it is designed
and they will be maybe grumpy because
you have a lousy UX that can be done
sure But most of the people using
applications, many applications, they'll
and they have no desire at all to do
anything else.
So if you just develop a good functional
UX friendly application so that the user
can do whatever the user needs to do and
wants to do,
you don't need security.
But we have people and it can be the
users as well
who want to do stuff with your data.
They should not do extracted
extracted
have more knowledge than they should
have. Share that knowledge with others
as well. And we call that hackers,
right? And that can be your in-house
users, but that can also be your
unknown hackers around. Good luck,
right? And that's the reason why we do
have security. We only have security
because people do bad things and that's
what you should keep in mind because if
you're only developing your application
from the UI perspective for the user and
from the security perspective, I want to
enable this for my user and I want to
grant my user this and I want to allow
my user that. That's in the end what you
do. But that's not your thought pattern
or that should not be your thought pattern.
lease privilege or need to know
that's the basic principle only provide
access to that what you should provide
to that user
I'll have a slide later also on entity
access but it already starts with do I
give read or write access to a member of
an entity
or not even read or write access that's
it starts with
and if they don't need it the answer is
no. Yes, but later no. Whatever comes
So when you start with your development
the first things you need to do is
create a menx project
define your modules
not necessarily your domain model. Yeah,
of course the majority of your domain
model, your start of your domain model,
but the most important thing is to have
the right distribution of your modules.
The domain model will follow and we all
know the domain model within Mandix is
always in change
more or less of course but there can
always be some additions to be done
after you have set up your domain modeling
modeling
from the first draft. Turn on your
security production not prototype demo
but production just like any production
running app. Why?
Because when you have it on production,
you have to configure everything. You
cannot skip the entity access for a
period of time and make a functional app
because prototype demo is only making a
functional app. So you can demo it for
users without taking care of security.
With production, you have to fix all
your errors. You create the page, put a
list on it. You should have at least
grant a role access to this attribute,
that member, that entity, whatever. You
all know that. And from now on, you will
rename that error list to the following.
It is your todo list. It's not an error
list. An error list makes it annoying,
make it negative. It is not a negative
thing. It is a positive thing. Because
when you go through these errors each
time, no those todos each time you'll
have to evaluate will I want will I
grant access?
Will I get read access or write access?
And no is also a long answer. It's not
that the to-do says it's on the page so
I have to grant access.
The opposite is true as well. Oh, it is
on the page. Hey, but this user should
not see this. So remove it from the
page. So it's not oh I need to grant
access no I need to decide
and I'll probably shooting myself in the
foot with nothing I say going in the
grass from my own feet. Yeah.
Yeah.
After you have set up your modules
internal security then you will define
your user and your module rules.
make them functional which also means
that all modules equal the user roles.
There will be modules which are maybe
the core of your application reflecting
the process of the application. So
module rules equals use rules.
But in many many cases you will have
modules where it is just about
the function and not necessarily the
user role. So
So
let me see your main business modules. I
picked an simple app and orders
invoicing and product catalog. Yeah,
this is your main business process.
All rules might be equal use rules
equals modu rules. But you also have
some functional modules or specific
business modules. In this case, one for
the back office and sales. a customer
will not be in there for example. So
still link to your user roles or tied to
your user roles but more strict and your
let me
your business configuration stuff
right I have the email connector I want
to send emails so one is managing the
fact that you can send an email and LDL
user or a selection of user roles will
be able to send an email or use that
and don't touch it some fancy back end
module for MX admin or colleagues right
so be very strict on who which modules
also when you add a new user role you
get the option and that option is ticked
in by default also create the module roles
roles
same as the user role in all modules.
Just don't
just don't unless you really really
really need it. But most of the time the
answer is no. Just don't and fix the
Sounds logical, right?
So kicking in a lot of open doors,
I hope. But
But
although it sounds quite logical what
I'm saying and you have to disputed your
main business logic or your main
business process etc etc
you need to have thoroughly knowledge
about what kind of app I'm creating what
kind of users do I have what kind of
process am I covering what do I need in
my application
so if you're not familiar with that
enough you make the wrong choices you
make the wrong distribution of modules
you make the wrong decision with those
rules and then
you will already have a foundation where
So it all starts with understanding of
the business to have a secure application.
application.
Make sense?
And if the business already is not able
to tell you exactly what they need,
you have a tough job.
And it is not only for the UI for the
process you are going to cover today you
understand the business it is more
important for the spiriting that you
so
finally you have understand the business
you have created an app you have your
module you have your user roles you have
your module all set up then you start
developing right
and the business needs it yesterday so
you're modeling quickly
But you still have to make an secure app.
app.
Create your user access rules based on
your context. So
if you're using user stories, it's
already there. As a certain user, I want
to have that idea. It already describes
what is needed in the functionality.
It's not directly giving you 100% the
answer on what kind of access you're granting,
granting,
but it is a good start. And you can also
question a product owner maybe a CISO or
whatever person is involved in the
company. Okay, which data are we allowed
to disclose to this user that user
and use that to configure your access rules
rules
and no access unless needed.
Need to know principle or least
privilege. Only read access if it is
used in the front end.
If it's not used in the front end, the
user is not using it or not only grant access
access
unless we need it somewhere in the process.
process.
Yes, but maybe later. Yeah, this user
should be is allowed to read this value.
Now my question is still is it used for
the C for the user? If the answer is no,
we'll still turn it off. Yes, but later
then we'll turn it on later.
It's not displayed but is used in the
front end. A nanoflow runs in the front
end as well. So if you want to consume a
value of an object in a nanoflow if you
or a value association if you want to
change it in a nanoflow you need right
access at least. So that also questions
yourself should I use a nanoflow for
this right. Um only direct direct right
access if needed as long as the user is
not changing a value by typing by
selecting by then do not want right access
access
if it is managed by microflow. The
moment it is calculated in the microflow
defined in the micrflow by default
always read access
unless it is like kind of kind of a
preset. So this a value is derived a
start date and an end date
based upon default if I select a start
date automatically the end date is
defined because the default is three
days. So, but you can change because
you're allowed to just but that's UX
and rename your MX admin. How many apps
name domin.com
where MX admin is the default master administrator.
administrator.
How many apps will have an MX admin will
have a master administrator who have
read right access on everything because
you use it as back end admin to fix stuff
stuff
and I see some eyes we have it. I
understand that you have your and I
understand that you have your go mode administrator
administrator
but please give it a different name
right it will help you
the only thing they have to guess is
just the password of your MX admin
and security you know security is just
a lot of layers
and the more layers,
if you spend time enough. You don't cry
too much and you can peel that onion and
then you will become
you will end up in the
core of the onion. And the same is with security.
security.
everything we do are just adding layers
to it. But in the end, we're all
hackable. You have to keep that in mind.
So, and I'm exactly changing the name is
another layer on your engine. All right.
Step by step instead of a big blow.
Don't model your application, turn on
security, have 20,000 errors and start
fixing that. You can do it like that,
but then you have to fix them all 20,000
at once. And that's a tough job
and you will make mistakes by definition.
Anonymous users,
you know them.
I see people, you know, yes, no. That's
the whole concept of an anonymous user.
You don't know them yourself. You you
might familiar with them, but you don't
know them, right?
Um because
in theory, maybe also practical, you
have eight billion possible users,
anonymous users of your application,
right? if you don't add IP restriction
So you have to be more careful. The
rules are the same.
Don't grant them more access than needed
the way how you will configure it from
technical point of view. It's exactly
the same but you should be aware more
and more and more more your decisions
have more impact and you it's just
something you should be aware of and
thus one of the things is if you start
interacting with anonymous user
anonymous user is allowed to enter data
pizza Mario I can order my pizzas
without creating an account for example
right collect your data from in uh
non-persistible entities
could be a good advice for known users
as well. But for anonymous users, this
is the must
for read and write access because if you
have anonymous users constraining you
only allowed to see and manipulate the
data which is yours
current user
that's a tough job.
I'm not saying it is impossible but I
know it's more complex and you will make
mistakes by definition.
By using non-presistable entities, your
objects are only in your state, only in
runtime, only in your session, it will
never hit the database. So no worries
about expot because you cannot even add
them to anible entity, right? And it's
not needed in this perspective.
And then when you have collected then
store it in the database through
micrflows and creating the destiny
object store them in the tables related
And what's the most important thing to
validate your input
because if it is just I enter it in a
non-possessible object and a microflow
or copy paste and it will store it in
the database. Yeah, I'm not sure if
you're doing it right. No, I'm sure
you're not doing it right.
So validate is everything which is
entered here is it correct? Is it valid
against what the user is entering? And
if so then you can start the process of
So far still with me? >> Yeah,
>> Yeah,
>> I'm not sure on the other side of my
Keep this in mind. Aliens must be
considered as existing.
Anonymous users are your aliens. [Music]
[Music]
never grant create and delete rights.
Yeah, but I need to create objects.
Yeah, do it through microflows
so that you can
more specific. Many objects which are
created in your applications are within
the context.
I'm or starting ordering a pizza. I'm
ordering this pizza and I I am ordering
this pizza. So, we create an order for
you as your user and the pizza we just
selected. We're not randomly creating an
order object because if you don't
recreate create access, you can create a
order object
and of course you can validate it before
you store it etc. But why would you not
even tighten your security?
One microflow will create an order for
you and the selected pizza
and you can continue from that. The same
for delete. If you have delete, right,
we're allowed to delete everything which
is in the scope of the if course
but maybe there are rules many cases
there are rules.
So model it out in microflows always
always
because these bypass your entity access
which isn't challenge which you have to
keep in mind but you can use it for
tighter security.
We might make of course your exception
for your MX admin go mode. I want to be
able to do everything and fix data in
the back end stuff. I know but at least
because potentially that administrator
member access rights no access unless
I need it and if I need it only read
unless the user should be able to
manipulate it directly
that's it and that's how tight you
should do it so that nice button in your
naxis configuration
read access for all click on everything
is set to read it's very fancy don't use
it unless you know what you're doing and
yes I use it quite often because this if
you have 10 numbers one is not nothing
one is written right as well the other
one I read started read and I just
and Xbox I already mentioned
Do not forget to add Xbox to it.
You are allowed to read this or write on
that when it is
has a certain status is tied to you as a
user. If but do not forget the relations inside.
inside.
I have seen many many apps. I have seen
apps running in production where this
kind of situation has happened.
It's what I'm allowed to see my orders
and then on order lines nothing.
So I can read all order lines of anyone
but only read the orders of Yeah. But if
I cannot access the orders of others, I
cannot see the orders of them. Right.
But then the story of Derek, that client
is just a fancy UIX access point for a
normal user because if I want to read
order lines, I can read order lines. If
you do not add the file on
and everybody says, "Yeah, does not make
sense. Yes, of course, we're doing
that." Okay, I will challenge you. Go
into your apps on Monday or maybe on Saturday.
Saturday.
go through your security rules and ask
XOS I
there to take the bet that there is an
entity where it should be Xbox but you forgot
forgot
because it didn't have impact on your
test because you only show a list of the
and if you find such I know it you don't
have to tell me you can but it's not
And also be aware of associations.
Granting the right on an association has
There are some challenges which will use that.
that.
I'm not going to say anything more. Um
Um
pages now I mentioned already then I
want to highlight it again. Pages are
just a structured interface for the
normal user for the one who's using that
application because of the users getting paid
paid by
by
employer has nothing to do with security.
security.
So having in your widget right access
right disable so it's not editable text
field so I cannot change it. Yeah,
whatever. If I have right access, I have
The hacker will create his own front end,
end,
his own proxy.
Only access to pages when needed for
direct navigation. So if that page is
not bound to a navigation item or
directly to a button, do not grant
access. Yeah. through this microphone.
Indeed, if it is open by microphone, it
is open by the microphone and not by
>> Yeah. Okay. Micro.
Micro. Um,
Um,
yeah, let's say nice to have. Yeah,
they're for a reason there. We use them
But use them carefully.
We use them for page validation, we use
them for events on widgets, we use them
for back end logic. Um for user
interaction for example I was mentioning
that when I select an end date start
date the end date is calculated
automatically or when I add a voucher
then my order value is reduced according
Let me ask a question to the audience
also for remote audience.
If I add a voucher
to a order something like this
and the requirement is that the user
after entering the voucher it should see
the new calculated order value.
Where will you trigger that microphone
>> sorry
>> server site
>> server site yeah but what's the trigger
when will that mic what will trigger
that microphone button
button >> sorry
>> sorry >> send
>> send
then it's when I'm sending the
when I'm adding the voucher.
>> Okay, I add the voucher and then apply
or something like that
>> and then it's a recup.
>> Yeah. So, uh you'll enter the voucher
code and instead of clicking apply this
only or on change, it will be the Yeah.
So, that is an hidden bit trigger
basically. Yeah.
>> Yeah, I have a little before commit
event or something we execute before we
commit it. Those are two different things.
things.
So am I who answer that question?
>> Yeah. Is that before commit as an event?
>> As an event. No.
>> I agree with both answers
because I made it mandatory that the
user directly sees the the value
changing. So you want to have an
onchange event or a button click at
least some client action so that the
user is aware what the result is of the
added voucher.
But I also agree with you. No I agree
with that because you want to inform the
user. I agree with you regarding security
security
because if we change it in the client,
yes, we can trigger that miclow of
course on the server. But I will not say
that it is correct and then when we hit
save and we commit all the calculated
values are stored in the database in the
right way.
Probably it will but not necessarily.
So what will you do after you have
entered your voucher codes and after you
hit the save button or maybe you will
set proxy so that you intercept the call
from the save button to the server what
will happen there and then with before
commit you capture the right thing but
then I haven't the reason why I'm asking
a little bit because I'm not very fond
on before commit events but that's
nothing to do with bits security is more
with performance Because my question is
how often will that value be changing
and how often will you commit that order
with the status change for something
like that and the probability is that
you will calculate it once but the order
will be committed multiple times which
will result in a lot more before commit
events doing something which already has
been done. So not a before committ
but at least before you commit it it
should be
or confirmed that calculation is still right.
right. Yeah.
So don't trust your outcome as the
perfect truth and validate or
recalculate before commit. It was
already on the slide
and still right
users right if you connect a miclow to
something in the client data source
miclow a button a navigation item you
will get that message you will must be
allowed to use this micro right
but you are you familiar with these
they're for a reason they're they should
not be yellow they should be red because
that means there is microflow which is
not directly
connected with the client so normal
users will not use them
but still you are able to trigger them
because you have right to use them
how do you end up with that
which is your Creative Ctrl Ctrl + V
duplicating micrflows
creating a sub microflow out of an top
level micrflow which we demot to an sub
micrflow but we did not remove it. It
happens. We are creative. We're developers.
We like to reuse stuff but it end up
check if it's access
it's not used anymore
>> oh I'm so happy that you're saying that
because it's not only about just think
out the box from security perspective
that will be sufficient but it also mean
that that mic flow A and even the sub
it's is it used anywhere because it
ended up here for a reason. So check it
garbage.
I had a fourletter other words. um
remove it, evaluate the use and of
input parameter manipulation
and sending in your order that's
validated and the microflow runs with
that order context.
Um isn't your order entering that
miclow? Is it really your order which is
entering your micro or is an proxy
between changing stuff? You don't know.
Yeah, you should validate stuff in your
micro to ensure that everything was
happening is really allowed.
Is that customer submitting that order?
Is that the order which is submitted is
that of the current customer? Yes or no?
Validate all that kind of things. So
that will only do the things what they
are allowed to do because the mic flows
and we have the ability to do everything
we're not allowed to do by default.
Internal security mic flows benefit is
security is checked. The drawback you
want to do stuff which is not allowed or
that user is not allowed. That's a tradeoff.
tradeoff.
So bypassing the entity axis which is
the default
and some developers not even know
just working with it
you can have a tighter spirit because
you can enable you're using do stuff
but you can also do stuff which you're
>> which also results that if you do a retrieve
get
then it will get everything without the
constraints you have to put on your
security and most of the time because of
the process it does not harm because you
retrieve the order lines of that order
or orders of the customer. So the
hickbot itself is already strict enough.
There are also situations where that
does not apply and you should be aware
of it
because that will allow you to do or the
stuff is happening in the microflow
which is not expected and most of the
time it is about not expecting is a data
source microflow. If we retrieve the
data it will retrieve it will never be
shown in the client if you're not
allowed to see it.
But that's not the situation where you
want to end up. You're dreaming over
your data, having everything on the
server, and then from the server to the
client. The client says, "Yeah, I'm not
allowed to show this, so we're not going
to show this."
This is nice, but it's not screenish pure.
pure.
I'm completely lost. Oh, yeah. And this
is one of the last or the last, the
smaller brother of the mic.
or niece, nephew, sister, I don't know.
It's the nanoflow.
It looks the same. You model it the same.
same.
I see yours.
You're not completely agree with that
sentence. It is the same. You model it
the same. It looks the same.
>> Feels the same, but not all options are different.
different.
>> Not all options. the fact that there are
different options
uh call Java action
>> lacking although you have to call
JavaScript that's not possible in the
microflow and you have of course a lot
of more client actions which are
they're great
but they're running in the client so if
you want to change a value I have right
access needed if you're changing an
association the same you you want to
create, if you want to delete and
execute it in a microflow h sorry in a nanoflow
nanoflow
then you should have the access rights
to execute this which breaks your
security or can break your security be
So my
way of working is I never use a nanoflow
unless I need a my nanoflow
because I want to do some stuff fancy
stuff in the client. I want to different
interaction and many times then I will
call in mlflow in that moflow to do the
things which I want to do in the end.
Do not make the thought the wrong
thought of oh I will use a nanoflow
because it runs in the client so that
will increase my performance of my app.
Good story, wrong choice.
Because if the performance of the app is
lacking in the first place, and I'm
talking about the desktop app, of course,
course,
then the answer is not a nanoflow, but
first follow our performance workshop.
You will be able to create more performs
in the first place.
And it's not a joke.
Of course using nanoflows for fancy
interaction. Great.
And of course you can do some
performance optimization using mic
nanoflows but not for the real stuff the
data stuff. And the moment we said yeah
but I'm creating a native offline app so
I'm stuck to nanoflows.
Good luck. We also have a native version
but that's a whole different ball game.
>> That's not what I'm saying here. What
are the implications of having a native
offline application where you have read
and write access on every entity in
every association for every what are the
implications for like the security
implications for that application
>> I'm trying to browse
back which is not happening somehow
For me, a native application is an alien.
So the same concept apply.
I'm not going to ground create and
delete and and and and and write access
on my entities because I'm creating a
native front end native offline front
end from it because that's what you're
basically doing separate
and you still might want to have
persistable objects you create but sync
them to your final entity. So treat them
like a non-persistible
and the sync is done when you sync from
your device to your
back end basically and how that's a
little bit out of scope for project 101.
This is a few steps further but the
principles is basically the same
technically a little bit more complex
and more challenging. I I
So,
There you go. So, this was my last
slide. Any
questions on everything I try to bring
across? Any additions to what I taught?
Looking also to
for the
>> No, no,
>> no questions.
>> No questions from my side.
>> So, we have one more question. Um
why don't we have something like data
sanitation or prepared statements and
semantics when it comes to user input
that could possibly danger the database
or allow hackers to do
unruly stuff within the database. Um in
high code projects you have to have data
sanation prepared statements. Why do we
not have it in code?
That's a design choice, an architectural
choice, but you can still do it, but you
have to set it up yourself by using the
micro in the right way. I'm not saying
that is exactly the same, but that's the
the way how you should
handle it by working in it is covered or
it is not covered. It is still possible to
to
be in danger of certain statements that
could be filled in. for inance a
password field where someone would fill
in like select star from database and
the table or something like that. No,
that's that's that's captured that's
that's that's captured in the runtime.
But there will be for example a workshop
either exactly at this moment or
tomorrow on 2 o'clock one that's about
files and uploading files where you
could hack around and you can fix that.
That will be explained in a workshop
today or tomorrow. Um so there are still
OKL the same you can do stuff in OKL
which you have to capture as well but
from just strings that's that's filtered
in directly on that attribute if you use
that attribute in your microflow and
doing stuff that you should be aware of that.
that.
Renee, would you be so kind to repeat
questions or remarks of online?
>> Yeah, this was a very long question. Yeah,
Yeah,
>> there was a question about how do we how
do you call that in
>> data sanitation or prepared state?
>> Oh, prepared status and data segregation.
segregation. >> Sanitation.
>> Sanitation.
>> Sanitation. Oh, sanitation. Now I hear
sanitation. Yeah, data sanitation. But
that's that's captured on the manage
runtime for the default input boxes. But
that's not necessarily if you use that
input in your microphone. Yeah, whatever
you do with a microphone and also ok is
is can be challenging and
I answered on follow there is also a
trick on that. So follow that workshop as
as
uh related to this question. Good.
Good.
Any other questions from Rodam?
No. Any questions from No. Then
>> oh there is a question. >> Oh
>> Oh
everybody was right. Yeah we can go. No
>> if security access is applied to
microflow and it's required to
manipulate data then it enforces us to
provide read and write access to
members. Is it secured way to do?
>> No. That's exactly what you when you
turn on your depends. That's the first
and the first. The question was if we um
want to change or manipulate a member in
a micrflow or create an object or delete
an object
and we turn on security apply entity
access in a microflow then we need to
grant access on entity level.
If this only about in that microflow a
change is made or an action is done
which is not allowed so I grant access
then you have to be aware that the user
can execute that change or that delete
or that create also outside of that microl
microl
in any case any scenario
and if that's okay then why not
>> but I know that is 99.9%
therefore turn off security no
appliancis off so that that microflow
can make the change without granting
full access for the user
and that's the reason why you should be
aware of if this micrflow is triggered
can it be triggered with inputs which
are not valid and can breach the
security when I'm allow them to change
the values in this microflow of the input
input
and that's what you should check. So do
not turn on security. Check your input.
That's the most important thing. And I'm
not saying that you never will turn on
But most of the time you want to have
more tighter security.
That's it.
>> All right. Then with that one job, have
a great evening. Have a good night. Have
>> And the stream.
>> Yeah, if I find my mouse
Thanks. Thanks.
>> You're welcome. Thank you. [Music]
[Music]
>> I will end it.
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
