Is there a way to set default values for custom user attributes in AWS-COGNITO at registration? I have a custom field "custom:status" and I'd like it to have a default value of "NOT_VALIDATED". I don't want the value to come from the client since the client might put "VALIDATED" instead and have extra permissions.
I have tried to set my status field in the pre signup lambda function but the value is ignored.
You can do it from a lambda trigger. In that case you don't have to update the attributes yourself but you can call adminUpdateUserAttributes on the user to update the attribute.
Another method would be to let it come from the client, but also send the value in the clientMetadata field of the request but encrypted. So that when it hits your pre-signup lambda you can make sure that the what the client passed is the same as the decrypted clientMetadata. If it is not just reject the registration as they tampered with the value.
Related
I have an application where I save some information on the session that later I assign to the model when I save it to the DB.
For example I have the following model saved by User1:
...
MyModel model = new MyModel();
model.name = mypostedModel.name;
model.type = HttpContext.Session.GetString("UniqueTypeForThisUser");
...
After I save the model in my DB, at the end of the post method, I clear the session with this line:
HttpContext.Session.Clear();
Let's say at the same time there's a User2 creating a new model and I have saved another value in the session with a unique key for User2. Same way as before, at the end of the post method I clear the session with the Clear() method.
Does this clear session method clear the session for all users, or only for one user. If for example User1 saves the model first and clears the session for all users, then the User2 will get his session variable cleared (lost) and will assign a null value to my 'type' column for the model.
For the documentation this was not clear for me. Thanks
You Can remove specific keys
HttpContext.Session.Remove("YourSessionKey");
The session object that you can access for example through HttpContext.Session is specific to a single user. Everything you do there will only affect the user that belongs to this session and there is no mix between sessions of other users.
That also means that you do not need to choose session configuration key names that are somewhat specific to a user. So instead of using GetString("UniqueTypeForThisUser"), you can just refer to the values using a general constant name:
var value1 = HttpContext.Session.GetString("Value1");
var value2 = HttpContext.Session.GetString("Value2");
Each user session will then have these values independently. As a result, calling Session.Clear() will also only clear the session storage for that session that is specific to its user.
If you actually do need different means for storing state, be sure to check out the docs on application state. For example, things that should be stored independently of the user can be stored using an in-memory cache.
Does this clear session method clear the session for all users, or only for one user.
The HttpContext is the one for the current request. Since every user has a different request, it follows that clearing the session on the current request only clears it for that request's user, not all users.
I defined a security check adapter and configured the property which is shown below.
<securityCheckDefinition name="MySecurityTest" class="com.sample.MyTest">
<property name="successStateExpirationSec" defaultValue="30" description="How long is a successful state valid for (seconds)"/>
</securityCheckDefinition>
The configuration means that when I pass the security check, I can access the protected resource under the scope for 30 seconds.
After 30 seconds, the server will force client to logout.
However, no user want their app repeatedly doing validation with high frequency.
We know we can increase the value of successStateExpirationSec, unfortunately, it cannot meet our requirement.
How can I extend the property "successStateExpirationSec" before the time
expired and without revalidation ?
It is not recommended to update the "SuccessStateExpirationSecond" after setting it and before it expires. I think Logical approach for your usecase is to determine the proper value "SuccessExpirationSecond" and set the properties to that value.
Instead of updating in the SecurityCheckDefinition in adapter.xml, you can also set it programatically by Extending "CredentialValidationSecurityCheck" .
Refer sample here .This allows you to set the default properties value.
Can someone suggest correct HTTP request header field to use to pass some flag using Rest API call. Can I use 'expect' request element for this use case?
Use Case:
Read client request header-->read the flag(say value is 1 or 0) --> do task A for value=1 or task B for value=0
No, that is not an appropriate use of the Expect header. Depending on your exact use case, you can use (a) a custom header, (b) a query parameter, or (c) embed the flag in the entity being sent to the server. Without more information, it's impossible to say which is most appropriate for your situation.
I'm trying to use the http://Astrid.com API, specifically to get data using the method under the "Request Format" section on this page - http://astrid.com/apidoc/file.README.html
The URL I built is:
https://astrid.com/api/7/task_list?app_id=[MY APP ID]&time=1&user_id=[MY USER ID]&sig=[MY REQUEST SIGNATURE]
And it returns this:
{"list":[],"time":1363131562,"status":"success"}
Seems like it worked, but does anyone know why the "list" array might be returning empty? I've created a bunch of tasks in my profile so it should be showing those.
Thanks!
You need to sign in first with the method user_signin. If successful you get a token.
Then you need to call the task_list method providing the token.
You do not need to provide a user id with the task_list method. It is only used to select tasks that you share with this user.
Example for signing in:
https://astrid.com/api/7/user_signin?provider=password&app_id=YOUR_APP_ID&secret=YOUR_ASTRID_PASSWORD&sig=SIGNATURE&time=1365715302.36&email=YOUR_EMAIL
Example for getting your tasks:
https://astrid.com/api/7/task_list?active=true&token=THE_TOKEN&sig=SIGNATURE&app_id=YOUR_APP_ID&time=1365715304.41
I faced with one issue, which I can't understand in Freeradius users file.
My goal is just authenticate external user "shad" with password "test".
I added line in /etc/raddb/users the following line:
shad Cleartext-Password == "test"
Result was Reject. If I change "==" operator to ":=" Authentication is successful.
So my question is the following:
Why I can't use "==" operator while FreeRadius documentation tells:
"Attribute == Value
As a check item, it matches if the named attribute is present in the request, AND has the given value."
And one more question.
In some resourses I faced with such lines:
shad Auth-Type := Local, User-Password == "test"
I tried and it doesn't work. Responce is Reject with log:
[pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
How the users file works
For the answer below, pairs is referring to Attribute Value Pairs (AVPs), that is, a tuple consisting of an attribute an operator and a value.
There are three lists of attribute(s) (pairs) that are accessible from the users file. These are bound to the request the server is currently processing, and they don't persist across multiple request/response rounds.
request - Contains all the pairs from the original request received from the NAS (Network Access Server) via the network.
control - Initially contains no pairs, but is populated with pairs that control how modules process the current request. This is done from the users file or unlang (the FreeRADIUS policy language used in virtual servers).
reply - Contains pairs you want to send back to the NAS via the network.
The users file module determines the list it's going to use for inserting/searching, by where the pair is listed in the entry, and the operator.
The first line of the entry contains check pairs that must match in order for the entry to be used. The first line also contains control pairs, those you want to be inserted into the control list if all the check pairs match.
Note: It doesn't matter which order the pairs are listed in. control pairs will not be inserted unless all the check pairs evaluate to true.
check and control pairs are distinguished by the operator used. If an assignment operator is used i.e. ':=' or '=' then the pair will be treated as a control pair. If an equality operator such as '>', '<', '==', '>=', '<=', '=~' is used, the pair will be treated as a check pair.
Subsequent lines in the same entry contain only reply pairs. If all check pairs match, reply pairs will be inserted into the reply list.
Cleartext-Password
Cleartext-Password is strictly a control pair. It should not be present in any of the other lists.
Cleartext-Password is one of a set of attributes, which should contain the 'reference' (or 'known good') password, that is, the local copy of the users password. An example of another pair in this set is SSHA-Password - this contains a salted SHA hash of the users password.
The reference password pairs are searched for (in the control list) by modules capable of with authenticating users using the 'User-Password' pair. In this case that module is 'rlm_pap'.
User-Password
User-Password is strictly a request pair. It should not be present in any of the other lists.
User-Password is included in the request from the NAS. It contains the plaintext version of the password the user provided to the NAS. In order to authenticate a user, a module needs to compare the contents of User-Password with a control pair like Cleartext-Password.
In a users file entry when setting reference passwords you'll see entries like:
my_username Cleartext-Password := "known_good_password"
That is, if the username matches the value on the left (my_username), then insert the control pair Cleartext-Password with the value "known_good_password".
To answer the first question the reason why:
shad Cleartext-Password == "test"
Does not work, it is because you are telling the files module to search in the request list, for a pair which does not exist in the request list, and should never exist in the request list.
You might now be thinking oh, i'll use User-Password == "test" instead, and it'll work. Unfortunately it won't. If the password matches then the entry will match, but the user will still be rejected, see below for why.
Auth-Type
Auth-Type is strictly a control pair. It should not be present in any of the other lists.
There are three main sections in the server for dealing with requests 'authorize', 'authenticate', 'post-auth'.
authorize is the information gathering section. This is where database lookups are done to authorise the user, and to retrieve reference passwords. It's also where Auth-Type is determined, that is, the type of authentication we want to perform for the user.
Authenticate is where a specific module is called to perform authentication. The module is determined by Auth-Type.
Post-Auth is mainly for logging, and applying further policies, the modules run in Post-Auth are determined by the response returned from the module run in Authenticate.
The modules in authorize examine the request, and if they think they can authenticate the user, and Auth-Type is not set, they set it to themselves. For example the rlm_pap module will set Auth-Type = 'pap' if it finds the User-Password in the request.
If no Auth-Type is set the request will be rejected.
So to answer your second question, you're forcing pap authentication, which is wrong, you should let rlm_pap set the Auth-Type by listing pap after the files module in the authorize section.
When rlm_pap runs in authenticate, it looks for a member of the set of 'reference' passwords described above, and if it can't find one, it rejects the request, this is what's happening above.
There's also a 'magic' Auth-Type, 'Accept', which skips the authenticate section completely and just accepts the user. If you want the used to do cleartext password comparison without rlm_pap, you can use:
shad Auth-Type := Accept, User-Password == "test"