Hi Carlo

Thanks for posting here. Carlo contacted me directly but I asked him to post here so that we could share the answers and get the help of other people on the forum. One piece of information that Carlo did not include is that he wants to submit data from a mobile application.

So far, Carlo, everyone has used the client_helpers library functions in order to submit records to Indicia as shown in the documentation like this.

<?php
if ($_POST) {
  $submission = data_entry_helper::build_sample_occurrence_submission($_POST);
  $response = data_entry_helper::forward_post_to('save', $submission);
  echo data_entry_helper::dump_errors($response);
}
?>

You can examine the source code itself to see exactly what is happening but it looks quite complicated to me and my impression has been that there is more complexity built in to the submission structure than is used so far.

The PlantTracker app posts from the app to an intermediate website (a Drupal website using the iForm module as there is also a web form). The intermediate website takes the post from the app and uses the functions above to forward the record to the Indicia warehouse. The website has to authenticate with the warehouse in order to submit the record but the app user does not log in at all. The records are not associated with a user ID and the person cannot read back their records.

Now the developers at Bristol University are building a new app where the user will be able to login. To do so the user first registers with the intermediate website and establishes a username and password. This website is still using Drupal and can use the EasyLogin module to automatically link the Drupal account to an Indicia user account. The mobile app will still submit records to the intermediate website and it will still forward them to the Warehouse but the app will authenticate with the intermediate website over an https connection and the record will be forwarded with an Indicia User ID.

Since the PlantTracker app needed a website too this was a very efficient solution to the problem. To interface directly with the warehouse you would need to write many of the functions of the client_helpers library within your app so that you could create users, authenticate them and send records. That sounds like quite hard work to me.

Some bits of documentation that might be relevant to logging in a user directly are the user_identifier/get_user_id service for creating users and the login control for authenticating users. Note that all the communication is done under the control of the digest authentication used normally between a website and a warehouse. For an app to do this it would need to have the 'website' password embedded within in it. That poses a modest security issue should the app be reverse engineered.

The developers at Bristol have said several times that they are happy to share their work. This could be very good for you if you are happy with the idea of submitting records via another website rather than direct to the Warehouse.

From this information, Carlo, can you say which method you would like to follow?

Regards,
Jim Bacon.

Hi Carlo

Let us get the Basic Page Tutorial working.
I have just tried it and was successful.
I made some mistakes so it did not work first time.
I found my mistakes by looking in the warehouse log.
The log is in the application\logs folder.
Make sure that $config['log_threshold'] = 4; in the file application\config\config.php
Do you see errors after trying to submit your form?

Jim

Hi Carlo

You can view the logs online instead. Log in to the warehouse and look in the Admin menu. Select Browse Server Logs.
If it is not present in the menu then ask the warehouse administrator to enable the log_browser module by editing the $config['modules'] array in \application\config.\config.php.

Jim.

Hi Carlo

Congratulations on getting the login control to work. Can you tell us what the problem was?

Did you get access to the warehouse log?

To send an observation I recommend you continue with the "TutorialBuildingBasicPage". This has been rewritten in the new documentation at https://indicia-docs.readthedocs.org/en … ndex.html. When you have got this working we can add support for images.

Images can be added to samples or occurrences using the file_box method or, if you are adding multiple occurrences with one form, the species_checklist method includes image uploading.

Jim.

Hi

To send an observation using Instant Indicia then I recommend you follow the Tutorial and look at section 5.4.1.

There is a more basic form described in UsingDrupalIForm but this may be out of date.

Have a look at the image_upload method for a simple upload control. This does not allow client-side resizing of images so it hasn't been used for a long time.

Jim.

Hi Jim,
the problem is that we should send observation maybe using the client helper via POST so to populate directly from our app, not opening a web form page. So i don't understand if there is a direct call to instant indicia or to warehouse to pas observations...

Hi Carlo.

If you create a Drupal user and you have the EasyLogin moduled enabled then the Drupal user will be associated with an Indicia Warehouse user, if one already exists with a matching email, or a new user will be created. What is the password of that Indicia Warehouse user? I don't know. Maybe there isn't one. Because the user authenticates with Drupal and Drupal authenticates with the Warehouse we have not needed a user password on the warehouse. Without a password user_helper::authenticate_user is not going to work. Maybe you need to create a new function called user_helper::create new user...

As I said in my first post, you may prefer to avoid communicating directly with the warehouse and use an intermediate website, copying the method devloped at Bristol University. The project manager fo the application developement at Bristol is Dave Kilbey.

Is your login problem that you cannot log in to the warehouse website or that you cannot authenticate using the client_helper library?

Jim Bacon.

Hi Carlo

You can only login with client_helpers to a user that has a password and that means you may only be able to login to users created on the warehouse directly, not via Instant Indicia.

When an item is deleted from the Indicia Warehouse the database record is marked as deleted but not actually removed. The login module should not allow you to login a user that has been marked as deleted but maybe there is a bug. Since this code is rarely used you may discover problems that no one else has.

Jim.

Well, I am guessing a little bit but, if you look at the specification of the User Identifier Service used by Easy Login you can see that no password is handed to the warehouse. Obviously without a password you can't use the client helper login. If you like, there is a gap in the code that you may have to fix.

It is unlikely that the user exists but isn't shown. If you had direct access to the warehouse you would look at the users table and see what is actually in the database. Easy login creates the Indicia user on first log in to Drupal I believe. Perhaps you are requesting new accounts, creating a Drupal user, but not logging in as those users.

Jim.

Hi Carlo
I think because you are trying to get your mobile application connecting directly to the warehouse you are treading on new ground, as other mobile applications developed using Indicia using an intermediary Drupal site as a proxy, so the mobile app logs into Drupal, not the warehouse. At least that is how I understand it.

The user_identifier web service is designed to create a user account on the warehouse effectively to give each recorder a persistent user ID, even across multiple applications. But as Jim pointed out it does not specify the password, as in the usage scenario the user does not actually log in to the warehouse. So, imagine the scenario that we have a website with its own login system, but when the user logs in, the user’s email is sent to the user_identifier web service in order to retrieve a user_id for the warehouse. The website can then keep a copy of that user_id in the user’s account and therefore can submit the user ID with future submissions.

The other web service I see you have been using, site_user/authenticate_user, was actually written by a new developer to the project who wanted to add a facility to allow a warehouse login to be authenticated against from a client website. It is not being used in our sites at the moment though because the user_identifier web service does what we want. So, as I understand it, you are correctly creating a user_id using the user_identifier web service, but then do not have a password so cannot use the authenticate_user web service. If your application development framework has its own login system, then it would make sense to use that and simply store the user_id in the account profile, which is exactly what we do with Drupal. However, if you want to use the warehouse to authenticate as you have been trying, then I suggest you modify the user_identifier service to generate a random password and to return it in the response when a new user is created, thus giving you the ability to log in. If you are able to take a look and submit a patch then let me know.

I hope this all helps,

Best wishes
John

Hi Carlo,

When you create a user in Instant Indicia (Drupal) that creates a Drupal user. If you have the Easy Login module enabled then a link to an Indicia warehouse user may be created. This may require that a user is created on the warehouse.

The warehouse username, password and ID is stored in the PostGreSQL database on the warehouse and IS DIFFERENT from the Drupal username, password and ID. You must understand this before you will make things work!!!

A person can register with multiple Instant Indicia websites with different usernames and passwords but EasyLogin ensures that they all use a single warehouse user, provided that the same email address is used at registration.

The User Identifier Service returns the warehouse user ID. The EasyLogin module stores this in the Drupal user profile but it is hidden unless you are logged in to Drupal as administrator. It is this Warehouse user ID that must be submitted with records.

Jim Bacon.

Hi Carlo,

I am going to use the words Drupal and Warehouse to distinguish between usernames, passwords and IDs. I will not use the words Indicia or Instant Indicia as I think we are getting confused.

Yes, we store the Warehouse User ID in the Drupal user profile so that this value is included when a record is submitted. This happens when data_entry_helper::forward_post_to() callls the function hostsite_get_user_id().

The client_helper library is designed to be independent of the website that uses it (i.e. it does not depend on Drupal) but iform.module provides this function which does exactly what you describe.

You ask about how the "Instant Indicia" (Drupal) password is stored. Drupal is open source so this is not sensitive. But why do you want this? The user submitting the record knows his Drupal password. He may not know his Warehouse password.

If, as John suggested, you modify the user_identifier service to return a random Warehouse password then it would be up to you to store it in Drupal, or any other system, in a safe manner.

Jim Bacon.