I need to use credential for log in to a system in AA for a bot that may run on different machines with a technical user for the system associated to each machine/bot.
Lets say the system is Stackoverflow.
Lets say I have two Virtual Machines,named:VM1, VM2
I name my credentials "Stackoverflow-VM1", "Stackoverflow-VM2" and want the automation to dynamically access those credentials, so that running on VM1 the automation will always use the VM1 credential.
I cannot find out how to use such a machine-dynamic access in AA while this is easy to do in other automation softwares and credential vault seems to be pretty useless without this functionality, especially with the extra concept of lockers...Any help?
Already tried:
1) The credential variables in AA will look like this from the client: $Stackoverflow-VM1(username)$, so i tried to simply write (not using the F2 variable list): $Stackoverflow-$Machine$(username)$ into the Set Text field but that results in the string "$Stackoverflow-VM1(username)$" written into the corresponding text field, which is consistent with the AA documentation:
https://docs.automationanywhere.com/bundle/enterprise-v11.3/page/topics/aae-client/bot-creator/using-variables/credential-variables.html
"Credential variables contained in the Credential Lockers can be seen and accessed only from the Insert Variables window."
2) I tried to create different lockers, where VM1 will only see "Stackoverflow-Locker-VM1" and a corresponding locker for VM2 exists. Now if i could create credentials with the same name but different content in each locker i could easily do this, but i cannot create identically named credentials, since they are aware of each other and not only defined in the context of a locker.
3) This page suggests its not possible: https://apeople.automationanywhere.com/s/question/0D56F00005dy3Ri/can-we-able-to-use-credential-vault-dynamically-?language=en_US
but its a 8 month old thread and possibly it has changed now. Everything suggested in this thread is not possible in terms of scalability.
Thankful for any input,
Thank you.
First thing I would suggest that you should always use F2 to fetch the variable list.
Returning to the question, to me, it seems that you have a system where you want to log in using different devices (bot runners) using different credentials.
It is possible by creating provided credentials values.
When you create an attribute for any credential, there is an option to mark the value as provided. That way, the associated users will get the credential request.
Each user will have to provide their own set of values. The bot can be created using those credentials. At run time, based on the user who is logged in, appropriate values will be fetched.
Disclaimer: I work for Automation Anywhere.
Related
I'm somewhat new to CouchDB and I'm wondering how to make private docs, that is I want to have a database where all docs are public (rw, or r using a validate_doc_update) except for few/some selected docs, how would I do something like that?
And to complicate things a bit more I want them to be private to / accessible by the admin but also varying number of selected users (but no others).
I'm thinking that perhaps I could have two keys in these docs called "private" and "private_users", set them to true and [user1, user2, user3], and somehow use that info to make the docs private / only accessible by them.
So essentially it's about users being able to create docs and have them visible to everybody or just themselves and other selected users.
One way to do this would be to make the database private by setting the Security admin and members lists to the owner (making the database completely private), and then route all calls to reading documents through a backend script which checks these properties of the document through an admin account and fetches and returns the content if conditions are met, but the thing is I'd like to do this through configuring CouchDB and do CORS HTTPS calls from the clients browser directly to CouchDB, with no script in the middle.
Is this possible?
There are several potential solutions to this problem:
The problem: For a given user, allow only specific access to a given document in the database.
Database per user:
Create one database for each user and use authentication on the database for that given user. Because views do not work across databases, you will have to replicate all needed data between the different user databases to allow for a view to contain both private and public/other users' data. Because normal users can not create/delete databases, you will need to have a separate process running which watches your database for changes and creates a new user database when a new user registers.
Smart Proxy:
Create a smart proxy that wraps all documents with the user credentials and filters all results.
Document Encryption on a per User Basis:
This solution is described in a google document which was mentioned on the development mailinglist. The goal of this solution is to create a P2P like system, where you can replicate data to nodes which you don't trust.
validate_read_doc:
Have a javascript function be called on every read, in the same manner as the validate_doc_update system is applied.
For more information:
http://wiki.apache.org/couchdb/PerDocumentAuthorization
So essentially it's about users being able to create docs and have them visible to everybody or just themselves and other selected users ...... Is this possible?
Not with just couchdb...
The permissions that you set with _security in a database only apply write level security on it.
Other wise most of the documents (except the design documents) are available for every one to read. With validate functions
you can impose further restrictions on who writes the documents but again there is no way to check who is reading your documents.
rcouch has a validation on read which can help you what you want to do. Other wise if you want to go with couchdb you could use a proxy for communicating with it.
I'm using Django-allauth for social and simple login. I want that when a user who hasn't signed up or isn't logged in makes a shortlist of items, the shortlist is still present when the user signs up or logs in. So I'm using Django-lazysignup.
Right now, a new lazy_user is created everytime I'm not logged in with Facebook, or it gives me a "column user_id not unique" error. The shortlist is also not converted.
How do we integrate the two? Or how do we do this without using lazysignup?
Any help on this would be great, thanks!
Have a look here:
https://github.com/pennersr/django-allauth/blob/327f5b60f31e9b3db18d461266084a44f04888dc/allauth/account/adapter.py#L117
and here:
https://github.com/pennersr/django-allauth/blob/327f5b60f31e9b3db18d461266084a44f04888dc/allauth/socialaccount/adapter.py#L40
Here, a new User instance is created for local and social users respectively. These adapter methods can be overriden, and instead of spawning a new instance they could be changed to return an existing lazy user instance.
With django-allauth out of the box you will probably run into the problem that you don't have access to the request instance here, but I am willing to adapt allauth to match your use case...
You could use a custom user model (Django 1.5) tweaked in a way, so that it uses the session key as identifier for example.
Later on signup.. just fill in the username and/or email etc.
This could make sense if you want to save the lazy users interactions even if they do not sign up (e.g. for statistical usage). I have not tested this.. but it might work. :)
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 have multiple CF applications running on the same server under the same domain name. One of them, let's call it Portal, is intended to be the single sign-on for the other applications, which let's call Atlas and P-Body. Normally you would set some variables in the session scope to handle login info:
function Login()
{
session.auth = structNew();
session.auth.isLoggedIn = true;
session.auth.id = GetCurrentUserId();
}
But the session scope is only shared within one application, not the entire server. This means that any user who logs into Portal will stay logged in, but if they try to navigate to Atlas or P-Body, they will have to sign in again.
In this case, how would I 'share' the session scope so that all the applications on a server can get access to it? The only way I've been able to come up with is to use client variables and set a data store so that it's shared between applications. Then the code becomes:
function Login()
{
client.auth = structNew();
client.auth.isLoggedIn = true;
client.auth.id = GetCurrentUserId();
}
function Logout()
{
structDelete(client, "auth");
}
The thing to watch out for here is that, because the client variable is not cleared on session end, we have to manually clear it in the OnSessionEnd handler.
Is this the best way of handling single sign-on in ColdFusion? If so, are there any drawbacks to using the client variable, or pitfalls to watch out for?
Update: I just tested the client variable method and it looks like only the hitcount, timecreated, lastvisit, and urltoken are shared between applications, so I'm back to square 1.
Posting this as the answer given new information.
Caveat
Ensure that all of the applications have either a) unique application scope names for persistent variables, or b) all application scope variables for the same purpose are named the same.
Alright, with that out of the way, if all of your applications are on a single domain in subfolders, then change this.name or the name attribute of cfapplication the same, and all of the applications will share the same session and application scope variables. This will ensure that if you use session.loggedin in one app, that same session.loggedin variable will be available to all applications with the same name under that domain.
You just have to test carefully to make sure that you don't end up using Application.LoginService in Portal for your LoginService.cfc, and Application.LoginService in Atlas for either a different LoginService.cfc, or a completely different purpose altogether.
Single Sign On (SSO) is not an easy thing to do and there are several very expensive products out there that help to prove that.
Fortunately, there are some free OSS projects out there are well.
There are also many other considerations with SSO that make its implementation difficult, like how do you handle it when a user clicks "Log off" on one of the sites? Do you log them out of all of them? If so, how?
If you want to do SSO right, you need to look at using an SSO solution, like Shibboleth (FOSS), or Atlassian Crowd (Reasonably priced commercial solution).
If you do not have the resources to use an SSO product like those above, then you will end up hacking around the current security restrictions that make SSO so difficult.
You're very close with the client variable solution.
Set up a remote database that all applications can speak to, either through the DSN, or through another single point of entry (ie. a WebService)
Decide on a common way to identify users across all your applications (ie. come up with your own unique sessionid, perhaps based off of CFID/CFTOKEN, CreateUUID(), or anything else you can guarantee is unique).
Build your authentication process so that when someone authenticates somewhere in your application farm...anywhere...that unique sessionid is stored to the remote database.
Pass that unique sessionid from app to app. Perhaps append it to your hyperlinks, or store it in client variables (cookies) that you mentioned earlier.
Finally, in your application logic that checks to see if someone is authenticated, before forcing them to login again...use their client variables (or the passed unique sessionid) to check back with the remote datasource, and auth them if you have found/verified it.
This is an oversimplification, but is the foundation for SSO, and should get you thinking in the right direction.
PS: Keep all your applications on the same domain, if possible (xx.mysite.com, yy.mysite.com) so that your client vars (cookies) can be set to be domain-specific, allowing them to traverse the application farm as you need them to.
Use the server scope. It is shared across applications.
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0c35c-7fdb.html
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.