WHMCS Pass variable to server provisioning module - whmcs

I'm trying to figure out how to pass a value from an order form to my server module.
For example on my order form a client can set a username, now I would like to pass the username to the server module to set the service up automatically.
Can one use placeholders in module setting fields to retrieve the data a client entered?
Any help is apprecitated.
Regards Stan

If you check the WHMCS Sample Provisioning Module, in the provisioningmodule_CreateAccount function the username is passed in $params array as $params['username'].
The same goes for the password and other config options.

Related

Update secret parameter in Jenkins Job

I have a lot of free-style jobs in my Jenkins instance. I create them with Jenkins API (generate XML-file with configuration and post them by "http://my-jenkins-instance:8080/createItem?name=JobName").
There is one problem - I can not generate value in secret fields. For example, I want such a config:
Inject passwords to the build as environment variables -> Job passwords.
And I need to set 123 to Password field.
I can not do this through XML because it appears decoded in XML. Something like this: {AQAAABAAAANwHq0hsSF6...}
I want to set the value to this parameter
So my questions are:
Can I get the decoded value of a plain password through some API? So I could send 123 and get {AQAAABAAAANwHq0hsSF6...} back.
If not, can I set secret value some other way? I can only think of using Selenium but it is too slow (comparing to API).
I have found the solution.
I can set the value as a plain text: <value>123</value>, create or update a job. Then I need to disable and enable the job.

LDAP simple bind parameters

I am trying to use ldap for a flask application .
The app.config['LDAP_PROVIDER_URL'] = 'ldaps://appauth.corp.domain.com:636'
(I have replaced the domain for the original name here)
In another script in need the following ldap details
conn.simple_bind_s(
'cn=%s,ou=Users,dc=corp,dc=domain,dc=com' % username,
password
)
How do I find the OU,or can i ignore OU and drop it from above. Please let me know if other parameters are correct. I don't know LDAP
The general idea is that you bind as an application account with search privileges to locate the user account, e.g. by his email address, displayName, etc., and then use that DN to rebind using the password he supplied.

Replace a String in Custom Connect To Statement in qlikview

I am using a REST Connector in Qlikview and i need to pass a variable to the CUSTOM CONNECT TO Statement when connecting to a Web Service.
CUSTOM CONNECT TO "Provider=QVRestConnector.exe;url="http://test.example.com?auth=2334342assa13"
Now, instead of the auth token directly getting passed, i need to provide it at the RunTime. I tried the below but its not working.
Let vToken="a3122423421f";
"Provider=QVRestConnector.exe;url="http://test.example.com?auth=$(vToken)"
Try to replace
Let vToken="a3122423421f";
With
Let vToken='a3122423421f';
A string in QlikView is defined with the ' character, " represents for instance field names.

Which parameter is used for authentication in LDAP

In case of LDAP authenticaion, what are the parameters that are generally used for authentication. I guess using DN would be a headache for users logging in via ldap because it is too large to remember.
How is the option of using uid or sAMAccountName for authentication where in my implementation, I retrieve the dn of the corresponding uid or sAMAccountName and proceed to authentication.
Am I going the right track?
In LDAP, a connection or session can be authenticated. When an LDAP client makes a new connection to an LDAP directory server, the connection has an authorization state of anonymous. The LDAP client can request that the authorization state be changed by using the BIND request.
A BIND request has two forms: simple and SASL. Simple uses a distinguished name and a password, SASL uses one of a choice of mechanisms, for example, PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, GSSAPI, and EXTERNAL - all of which except for GSSAPI and EXTERNAL are too weak to use in production scenarios or mission-critical areas.
To Use the simple BIND, construct a BIND request and transmit it to the LDAP directory server. The LDAP directory server will respond with a BIND response in which is contained a result code. The result code is an integer, anything other zero indicates that the BIND request failed. If the result code is zero, the BIND request succeeded and the session authorization state has been changed to that of the distinguished name used in the BIND request.
Each subsequent BIND request on the same connection/session causes the authorization state to be set to anonymous and each successive successful BIND request on the same connection/session causes the authorization state to be set to the authorization state associated with the authentication ID, which is the distinguished name in the case of the simple BIND, but might be something else entirely where SASL is used - modern professional quality servers can map the incoming names to different DNs.
Whichever language is used, construct a BIND request, transmit it to the server, and interpret the response.
Update:
If the distinguished name is not known, or is too cumbersome (often the case with web application users who don't know how they are authenticated and would not care if they did know), the LDAP application should search the directory for the user. A successful search response always contains the distinguished name, which is then used in a simple BIND.
The search contains at a minimum, the following:
base object: a distinguished name superior to the user, for example, dc=example,dc=com
a scope: base level, one level below base, or subtree below base. For example, if users are located subordinate to ou=people,dc=example,dc=com, use base object ou=people,dc=example,dc=com and a scope of one-level. These search parameters find entries like: uid=user1,ou=people,dc=example,dc=com
a filter: narrows down the possible search results returned to the client, for example (objectClass=inetOrgPerson)
a list of requested attributes: the attributes from an entry to return to the client. In this case, use 1.1, which means no attributes and returns on the DN (distinguished name), which is all that is required for the simple BIND.
see also
the links in the about section here
LDAP servers only understand LDAP queries; they don't have "usernames" like you and I are used to.
For LDAP, to authenticate someone, you need to send a distinguished name of that person's (or entity's) entry in LDAP; along with their password.
Since you mentioned sAMAccountName I am assuming you are working with Active Directory. Active Directory allows anonymous binds - this means you can connect to it without providing any credentials; but cannot do any lookups without providing credentials.
If you are using python-ldap and Cython (and not IronPython which has access to the various .NET APIs that make this process very easy); then you follow these steps.
Typically you use a pre-set user that has appropriate rights to the tree, and connect to the directory with that user first, and then use that user's access for the rest of the authentication process; which generally goes like this:
Connect to AD with the pre-set user.
Query active directory with the pre-set user's credentials and search for the distinguished name based on the sAMAccountName that the user will enter as their "username" in your form.
Attempt to connect again to Active Directory using the distinguished name from step 2, and the password that the user entered in their form.
If this connection is successful, then the user is authenticated.
So you need two main things:
The login attribute (this is the "username" that LDAP understands)
A LDAP query that fetches information for your users
Following is some rough code that can do this for you:
AD_USER = 'your super user'
AD_PASSWORD = 'your super user password'
AD_BIND_ATTR = 'userPrincipalName' # this is the "login" for AD
AD_URL = "ldap://your-ad-server"
AD_DN = "DC=DOMAIN,DC=COM"
AD_LOGIN_ATTR = 'sAMAccountName' # this is what you user will enter in the form
# as their "login" name,
# this is what they use to login to Windows
# A listing of attributes you want to fetch for the user
AD_ATTR_SEARCH = ['cn',
'userPrincipalName',
'distinguishedName',
'mail',
'telephoneNumber','sAMAccountName']
def _getbinduser(user):
""" This method returns the bind user string for the user"""
user_dn = AD_DN
login_attr = '(%s=%s)' % (AD_LOGIN_ATTR,user)
attr_search = AD_ATTR_SEARCH
conn = ldap.initialize(AD_URL)
conn.set_option(ldap.OPT_REFERRALS,0)
conn.set_option(ldap.OPT_PROTOCOL_VERSION,3)
try:
conn.bind(AD_USER,AD_PASSWORD)
conn.result()
except:
exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()
# Exit the script and print an error telling what happened.
sys.exit("LDAP Error (Bind Super User)\n ->%s" % exceptionValue)
try:
result = conn.search_s(user_dn,
ldap.SCOPE_SUBTREE,
login_attr, attr_search)
except:
exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()
# Exit the script and print an error telling what happened.
sys.exit("LDAP Error (Search)\n ->%s" % exceptionValue)
# Return the user's entry from AD, which includes
# their 'distinguished name'
# we use this to authenticate the credentials the
# user has entered in the form
return result[0][1]
def authenticate(user,password):
bind_attr = AD_BIND_ATTR
user_dn = AD_DN
login_attr = '(%s=%s)' % (AD_LOGIN_ATTR,user)
data = _getbinduser(user)
if len(data) == 1:
return None
# Information we want to return from the directory
# for each user, season to taste.
info = {}
info['name'] = data['cn'][0]
info['email'] = data['mail'][0]
try:
info['phone'] = data['telephoneNumber'][0]
except KeyError:
info['phone'] = 'Not Available'
conn = ldap.initialize(Config.AD_URL)
conn.set_option(ldap.OPT_REFERRALS,0)
conn.set_option(ldap.OPT_PROTOCOL_VERSION,3)
try:
# Now we have the "bind attribute" (LDAP username) for our user
# we try and connect to see if LDAP will authenticate
conn.bind(data[bind_attr][0],password)
conn.search(user_dn,ldap.SCOPE_SUBTREE,login_attr,None)
conn.result()
return info
except (ldap.INVALID_CREDENTIALS,ldap.OPERATIONS_ERROR):
return None
One small expansion on Terry's excellent comment. If you store all your users in the same part of the DIT, and use the same attribute to identify them, you can programmatically construct the DN, rather than searching for it.

multiple user logins in jmeter

I am using jmeter to test a php application. I need to create a different thread with a unique session for each user. Because in my application you can only have one login per user at a time so putting 100 times the same user I will not get to any conclusion.
I have created 40 users user0,user1....user39 with the same password is there a way to automatically create simultaneous threads for each of them?
Thanks
I just implemented this using jmeter for an app that uses Spring Security (It would be very similar to PHP). This is fairly straightforward, basically:
1) Create a new CSV file using a text editor
Ex: CSVSample_user.csv
username1, password1
username2, password2
2) In jmeter, create a CSV Data Set Config element
Thread Group>add>Config Element>CSV Data Set Config
=> Assign variable names (see image)
3) Create an HTTP Request element
Thread Group>add>Sampler>HTTP Request
=> Create a POST with parameters, have the variable you created
put the values for the parameter. (See bottom image).
NOTE: There are other elements you need, such as cookie manager, etc. Also number of threads needs to be set to the number of login users.
You can use a CSV Data Set Config. This control will allow you to use an external source of variables.
Add -> Config Element -> CSV Data Set Config
You must set the variable names, something like:
Variable Names (comma-delimited): USERNAME,PASSWORD
Then you can use the variables in your HTTP Requests parameters like:
${USERNAME} and ${PASSWORD}
I realize this question is over a year old, but I just came across the same issue and thought I'd add my solution for anyone else who stumbles upon this issue.
If you have a sequence of usernames and passwords that are simply differentiated by numbers at the end of their values, you can use the __threadNum variable to log them in. So for the value of username you might say user${__threadNum}.
This solution is simpler than including a csv but only works where you have a list such as the one you suggested in your question.
keep csv file and testplan (i.e jmx) in a same folder and recheck the variable name in CSV datasetconfig and http request for any typing error.