IBM Domino: Error When Submit Document - lotus-domino

I create a new database, and when I create a document and submit to this database from the web, I got an error in the console:
HTTP Web Server: IBM Notes Exception - The certificate table does not contain enough valid certificates to verify the public key of its owner.
But if I submit a document to another database in this server, I can save successfully. Where can I setup or need do some other step? When I open a form in this new database, I also got this error in a message box. I tried to change ACL for the new database but it did not work.

If you're getting this error while attempting HTTP access to a specific database, it probably means that there is something odd about the signature on one or more design elements in the database. I.e., the signature on the form, the query save agent, or some other design element was done with an id that doesn't share a common root certificate with the server.
Try using the Domino Administrator client to sign the database, either with the server id or with another id in the same organization.

Related

Tableau Extract refresh through API call from python. Getting unauthorized access (401002 response)

we are working on setting up tableau extract refresh through API invocation. We are using Personal access tokens from tableau for authentication. While we are able to establish the communication and are able to retrieve details on tableau site, we get a 401002 response when we try for extract refresh. Is there a need for an additional privilege to the access token to set the extract refresh.
Any pointers on this would be of great help!
Make sure that the user whose PAT you're using is the owner of the workbook (and hence the extraction schedule). If not, the extraction request will fail. Alternatively, if the user cannot be the owner, they must be server administrators or site administrators on your Tableau server.
Also make sure you already have a schedule for the extract refresh. If one doesn't exist, you can create it with the Create Schedule method (with the API this can only be done by server administrators, on the browser the owner of the workbook can do this).
From the Tableau API docs, also note that "A REST request to start a refresh task will fail if the task has been put in the task queue in any of these ways, or is already in progress". This might also be one reason why it fails.

Authenticating Cloudant one db per user

I apologies in advance - for this question needs a bit of background, which is likely to be long winded:
I'm trying to build an app which works offline with PouchDb. PouchDb will sync with Cloudant.
Technologies used:
Hapi, SQL, Vue, Cloudant, PouchDb
I have built a little hapi.js service to sign up / authenticate users. When an "account owner" signs up - they are added as a new user to a SQL database.
Using Cloudants API, I provision a new database (with a random name), and set security on the database so the new user has access.
I save the security (DB name, User name, and password) as metadata back to the user in the SQL database.
A very similar approach to here: https://www.bennadel.com/blog/3208-provisioning-cloudant-couchdb-databases-from-auth0-for-a-database-per-user-architecture-in-angular-2-4-1.htm (indeed, I based the above on this).
When the "account owner" logs in, the SQL DB is queried - the MetaData retrieved and sent down to the client side vue app. The PouchDB remote string is then populated with the Cloudant DB name, User name, and password.
eg:
const remoteDB = new PouchDB(`https://${name}:${pass}#0000-0000-bluemix.cloudant.com/${DBname}`);
This all works: PouchDB can talk to Cloudant - and data is going to and from without issue.
The "Account owner" is able to give read/write access to other people ("Staff") to their cloudantDB. When they add a new Staff Member, the Staff Member is added to the SQL DB. Using cloudants API, I create new security credentials for this user so that they can access the DB- (I do NOT create a new DB) and save them to the Staff Member in the SQL db as metadata...
The new staff member is sent an email - they set their username and password on the SQL db, and can log in. The Cloudant meta stuff is picked up... etc etc... PouchDB / Couchdb talks to each other - this also works.
Initially I was a bit concerned about sending this meta / credentials down to the client - I wanted to use a JWT or something... But then I saw this answer to another question:
https://stackoverflow.com/a/30417620/714950
So passing credentials down seems to be how its done in Pouch/Couch/Cloudant etc. I've got to be honest - I find the whole thing works like 'magic' - like its too good to be true, and that worries me a bit as I don't really understand it. I might be doing something terribly wrong.
Now for my question(s):
I'm passing these credentials down - is this safe? How would I reset / time out the username and password.
When they log out, I wipe the data from Pouch?
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data? so I guess I would need to persist the data in Pouch for when they log in again?
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
I'm also unsure how I validate the data... making sure that which gets saved to the DB is valid etc...
I suppose I'm just trying to get my head around this - I've been googling and reading everything I can, but it doesn't quite answer my questions.
Thanks
[** Just had a thought...
Thinking about it, I don't actually need to create the staff user within the SQL DB.
The Account Owner is set up - the DB is created in Cloudant, and credentials applied.
Not just had a thought: Theoretically, when a staff member is added - I only need to set them up inside Cloudant, and write their ID to the "Account Owner" as meta data so that they can be removed etc.
This way, a staff member could log in directly to the Cloudant DB.
However, I generate the security credentials using Cloudants API - so the staff member won't know what their username and password is. I don't want to send the username and password in an email.
Is there a way I can handle this? Am I able to specify a username and password when creating the security credentials? How do I handle things like password resets on cloudant?]
Thanks
I'm passing these credentials down - is this safe?
If your site is served out over HTTPS, then a bad actor would find it difficult to glean the Cloudant username & password in flight. Your client-side app needs to retain the credentials for your app to be "logged in" (for it to retain the right to sync with the server). I like to retain the data in a PouchDB document (e.g. _local/auth - local documents are not replicated so reside only on the device you create them on). You are right to be concerned, however, about having database credentials floating about on a client-side computer. Some folks decide that that is not acceptable and implement their own middle layer. If you don't need sync (that is data can be altered at both client and server side), you might use PouchDB as a buffer for unsynced data and push it to your own API when you're online. You can then control authentication, timeout and access to the database from your own server-side code.
How would I reset / time out the username and password.
You can "log out" by:
deleting your client-side state e.g. deleting the _local/auth document.
making the key/password have no permissions on the client side. Without _reader/_writer/_replicator rights, a Cloudant api key and password is useless
Alternatively you could transmit the username & password to the client which could use them against the Cloudant POST /_session endpoint which gives the web browser a time-limited cookie. Your app could then "forget" the credentials until it needs them again.
When they log out, I wipe the data from Pouch?
Yes.
Can a user be 'logged in' and lose connection? Will pouch sync when they reconnect?
If you write your client side app correctly, it could function perfectly well with its local PouchDB data, whether it has an internet connection or not. This is known as an Offline First approach. As long as your credentials are still valid, your app can sync when a connection is re-established.
If pouch has NOT synced - and they log out (and I wipe Pouch) that would mean they would lose their data?
Correct. If you have only one copy of some data and delete it, you lose data :)
But what if they are using a shared computer? This data would be sat in Pouch DB waiting for someone to log in?
Correct. On a shared computer, another user's data may be visible to the second user. Just as if I left my Facebook session logged in on a shared computer.

Auth0 Test Connection tries to log into wrong database

I have created a client and database and associated the two. When I create a user in this database, I am unable to log in using the test connection button.
When I check my logs, I don't see any attempt to log into this connection, rather I see a failed login for the connection Username-Password-Authentication. The connection I am testing is named bens-connection, this is just a standard auth0 database.
Can you confirm which Test Connection button you are pressing. Is this Connections -> Database -> bens-connection then the Try connection tab?
Is your Client definitely associated with the bens-connection database?
Is your User definitely associated with the bens-connection database?
If so, then suggest you just copy out the URL when you hit the Try connection button and manually edit the connection name. Paste that into a URL and see if you can successfully login.
You should have a URL something like:
https://{{TENANT}}.auth0.com/login?client={{YOUR_CLIENT_ID}}&protocol=oauth2&redirect_uri=https://manage.auth0.com/tester/callback?connection=bens-connection&prompt=consent&response_type=code&connection=bens-connectionstate=sDZ8vs4tb2FqR3xnLpUnxIPhO7CiA5O4
You could also try the authorize endpoint using:
https://{{TENANT}}.auth0.com/authorize?client_id={{YOUR_CLIENT_ID}}&protocol=oauth2&connection=bens-connection&redirect_uri=https://jwt.io&response_type=token id_token&scope=openid email&nonce=123&state=xyz
Let me know how you get on, and I can update this answer based on further info.

how to authenticate to ldap server using mail id instead of user name

I have a created a ldap server . I registered some users in that server. For now i am able to login through server using username and password of users from my mac system.But now i want to login through server using mail id and password of users instead of username and password.How to change this setting in mappings of ldap in mac.
Go through this link https://help.apple.com/advancedserveradmin/mac/10.7/#apdB5DE1FD6-4D51-4C20-BB66-982DB85DF258. it helped me a lot. we have to give DN as mail=mailaddress,OU=users,dc=example,dc=com.
and password whatever we configured during server configuration.
I'd add a new Mapping-File to the DirectoryServices as stated in http://support.apple.com/kb/PH9293?viewlocale=en_US&locale=en_US. That way you can map not only the UID or the CN for logging into the machine but also the email-address. That way you will only have to store the email-address in the corresponding field that is also used by the mail server and the possibility that one time something gets mixed up due to incomplete changes is reduced.
On the other hand it might be a lengthy process to get everything right
Update: I've just written a blog-post about mapping LDAP-Attributes to DirectoryService-Attributes. It might be helpfull here: http://andreas.heigl.org/2014/06/05/change-opendirectory-mappings/

Secure client-side couchApp / couchDB user authentication

Background research:
User Signup in Couchapp/CouchDB through jquery.couch.js or Otherwise
http://blog.couchbase.com/what%E2%80%99s-new-couchdb-10-%E2%80%94-part-4-security%E2%80%99n-stuff-users-authentication-authorisation-and-permissions
https://issues.apache.org/jira/browse/COUCHDB-1175 - specifically "Ari Najarian" 's posts
Question:
To paraphrase the SO question I posted above:
"Essentially I want to have a signup form for registering an account in couchdb for a couchapp. This would entail creation of a new user in the couchdb _users database, and the creation of a new database, with the new user assigned the role of database admin. All that requires server admin credentials."
The answer to the previous question involved using an external separate server that was logged in to couchdb as admin to monitor couchdb and modify couchdb as desired in response to certain data events coming from a client.
My question is - is that the only way? Doesn't that defeat the whole purpose of couchdb's 2-tier web stack? Is there some way to modify a couchdb database from within a validation function which checks for "type == user" document while "internally"/separately logged in as an admin maybe?
I apologize if there is some straightforward way to do this and I just didn't find the right documentation.
Extra Problem Clarification:
There is the couchdb instance sitting at an internet address.
This couch database serves to a random client an html page and embedded javascript script that contains a signup/login form.
The client enters signup info (name, password) and submits
The JS script uses the XMLHttpRequest object to open a connection to the couchdb instance and sends...PROBLEM!
Problem #1 - If the credentials are stored in the code (to be sent as verification for new user database), then anyone could "view html source" and take over the database.
-OR-
Problem #2 - If credentials are not supplied and the request is sent anonymously, then a new user will be created in the _users database and a success reply message will be sent. But no new database was created for the user (and can't be without admin credentials) which the user can interact with for application-specific purposes (e.g. add/delete data). And - from the above couchbase blog link - if you have secured your database with roles/names against anonymous readers and validation functions to prevent anonymous writes, then an anonymous-made user account (e.g. a client who wants to register database space to use the app) can not do anything because an anonymous user cannot, for obvious security reasons, specify whatever roles they wish to have. Which means that the only way to have -functional- users is to create user accounts + associated databases as admin beforehand and then hand out these user credentials - so like a private invite system, yes?
To reiterate, is there any way, using ONLY couchdb and some combination of couchdb's authentication handlers, design document functions, client-side ajax, etc. for a connecting client to register and get a personal database (and ONLY that database obviously) they have access to and can interact with?
This isn't a PURE couch solution, but it's couch + node, and solves your problem:
Hi I haven't been around in awhile and didn't realize this was edited / link removed (plus policy of links not being answers! sorry...). I have been using couchdb on a project very similar to what you are trying to do, and unfortunately there is no way to do what you want to accomplish without tacking on another service to handle the admin-level access and creation of user database. Syncpoint-API can be used to facilitate this, but it is actually a nodejs service handling the signup/login and dedicated database setup.
So far though, Syncpoint has proven to not be 100% reliable and it does appear to be an abandoned project, due to CouchBase sucking all the r+d resources away from CouchDB dev.
I'm now moving to nodejs + socket.io as a transport layer, using node to handshake and assign a DB, and then further watching the couch _changes api on the server (via yet another node process) to then forward _changes through socket.io to the client. Also I have some "pure" couchapps running that serve public data mixed in with the private data.
My conclusion? CouchDB is a great product and has some great features, but for the more complex login/authorization schemes and other general application needs required in real-world dev, it's just not ready yet.