Bug 26692 - Add barcode image generator service for OPAC
Summary: Add barcode image generator service for OPAC
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Kyle M Hall
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on:
Blocks: 26777
  Show dependency treegraph
 
Reported: 2020-10-15 12:57 UTC by Kyle M Hall
Modified: 2024-03-19 00:58 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 26692: Add barcode image generator service for OPAC (3.53 KB, patch)
2020-10-15 12:59 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 26692: Add barcode image generator service for OPAC (3.52 KB, patch)
2020-10-15 13:01 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 26692: Add barcode image generator service for OPAC (3.52 KB, patch)
2020-10-19 11:17 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 26692: Add barcode image generator service for OPAC (3.53 KB, patch)
2020-10-19 12:43 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 26692: Add barcode image generator service for OPAC (3.66 KB, patch)
2020-10-19 15:44 UTC, Séverine Queune
Details | Diff | Splinter Review
Bug 26692: Add barcode image generator service for OPAC (3.72 KB, patch)
2020-10-22 08:22 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26692: (QA follow-up) Spelling correction (792 bytes, patch)
2020-10-22 08:22 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 26692: (QA follow-up) Respond with 401 if patron is not logged in (1008 bytes, patch)
2020-10-29 11:51 UTC, Kyle M Hall
Details | Diff | Splinter Review
Proposed mobile view (48.32 KB, image/jpeg)
2022-08-25 04:29 UTC, David Cook
Details
Proposed desktop view (93.72 KB, image/jpeg)
2022-08-25 04:29 UTC, David Cook
Details
Koha plugin proof-of-concept (4.98 KB, application/zip)
2022-08-31 02:13 UTC, David Cook
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2020-10-15 12:57:57 UTC
Some libraries would like to add a scannable barcode to the patron self service area of the opac for patrons who do not have their library cards with them. The existing svc/barcode on the staff side should work fine, but requires a staff login. It makes sense to duplicate this script but only require a valid patron login to use it.
Comment 1 Kyle M Hall 2020-10-15 12:59:43 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2020-10-15 13:01:06 UTC Comment hidden (obsolete)
Comment 3 Lucas Gass 2020-10-15 14:30:13 UTC
This doesn't work. When I go to http://localhost:8080/cgi-bin/koha/svc/barcode?barcode=123456789 I get:

Global symbol "$cgi" requires explicit package name (did you forget to declare "my $cgi"?) at /kohadevbox/koha/opac/svc/barcode line 94
Comment 4 Magnus Enger 2020-10-16 07:00:46 UTC
+1 for this! :-)
Comment 5 Kyle M Hall 2020-10-19 11:17:10 UTC Comment hidden (obsolete)
Comment 6 Kyle M Hall 2020-10-19 12:43:12 UTC Comment hidden (obsolete)
Comment 7 Séverine Queune 2020-10-19 15:44:50 UTC Comment hidden (obsolete)
Comment 8 David Cook 2020-10-20 03:11:15 UTC
Does it make sense to duplicate this script or to adapt it to the new API?

Also, can you elaborate on the use case? I don't really understand how it would be used.
Comment 9 Martin Renvoize 2020-10-21 15:54:41 UTC
Is the use case here so a patron can, for example, display their patron barcode on their phone to use in a self-service machine?
Comment 10 Martin Renvoize 2020-10-21 16:08:41 UTC
(In reply to Martin Renvoize from comment #9)
> Is the use case here so a patron can, for example, display their patron
> barcode on their phone to use in a self-service machine?

If this is the case.. I'd love to see a link somewhere in the OPAC to the display ;).. I think that would mean this service was less obscure and possible to lose in the future if someone doesn't understand the use case behind it ;)
Comment 11 David Cook 2020-10-21 22:59:08 UTC
(In reply to Martin Renvoize from comment #10)
> (In reply to Martin Renvoize from comment #9)
> > Is the use case here so a patron can, for example, display their patron
> > barcode on their phone to use in a self-service machine?
> 
> If this is the case.. I'd love to see a link somewhere in the OPAC to the
> display ;).. I think that would mean this service was less obscure and
> possible to lose in the future if someone doesn't understand the use case
> behind it ;)

Ohhh that's interesting! I reckon it should just be rendered on opac-user.pl without any added action. (In fact, when I look at my user account as a public library patron, I see my barcode on my user account page.)

I would be tempted to generate the barcode and store it somewhere, so that we're not re-generating the barcode for every patron for every page load. Barcodes rarely change, so I don't see why we'd want to regenerate it frequently. That being said, barcodes do change, and we have many different ways of updating barcodes, so keeping consistency might be too difficult.

That said, I wonder if using a database or a time limited file-based cache would actually be slower than just regenerating the barcode on each page load...
Comment 12 Katrin Fischer 2020-10-22 00:18:22 UTC
Isn't the goal here much simpler... just to make the service that we already have on staff side available in the OPAC? I know that the one on staff side is used for generating barcodes on slips and the like. I think this can be seen as another API we expose for customizations - Kyle named a possible one in his comment with the scannable barcode on the self service area. 

I don't think a "use" is strictly needed here but I would love a short paragraph for the manual or https://wiki.koha-community.org/wiki/APIs_and_protocols_supported_by_Koha to advertise the existing and new web service a bit more!
Comment 13 Martin Renvoize 2020-10-22 08:22:47 UTC
Created attachment 112156 [details] [review]
Bug 26692: Add barcode image generator service for OPAC

Some libraries would like to add a scannable barcode to the patron self
service area of the opac for patrons who do not have their library cards
with them. The existing svc/barcode on the staff side should work fine,
but requires a staff login. It makes sense to duplicate this script
but only require a valid patron login to use it.

Test Plan:
1) Apply this patch
2) Browse to /cgi-bin/koha/svc/barcode?barcode=123456789 from your OPAC address
3) Note the barcode image

Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 14 Martin Renvoize 2020-10-22 08:22:51 UTC
Created attachment 112157 [details] [review]
Bug 26692: (QA follow-up) Spelling correction

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 15 Martin Renvoize 2020-10-22 08:24:21 UTC
Well... the feature works as expected so I'm going to PQA.

I would like to see it documented somewhere, else I can see it becoming a forgotten feature.. even better I'd love to see it utilised somewhere.. like via a link added to the OPAC users account somewhere..
Comment 16 Kyle M Hall 2020-10-22 10:21:20 UTC
(In reply to Martin Renvoize from comment #15)
> Well... the feature works as expected so I'm going to PQA.
> 
> I would like to see it documented somewhere, else I can see it becoming a
> forgotten feature.. even better I'd love to see it utilised somewhere.. like
> via a link added to the OPAC users account somewhere..

I have made a pull request for the manual to document the barcode svc script!
Comment 17 Owen Leonard 2020-10-22 18:48:50 UTC
I think this shouldn't explode if you are not logged in
Comment 18 Kyle M Hall 2020-10-28 11:52:10 UTC
(In reply to Owen Leonard from comment #17)
> I think this shouldn't explode if you are not logged in

Should it 401?
Comment 19 David Cook 2020-10-28 22:40:10 UTC
(In reply to Kyle M Hall from comment #18)
> (In reply to Owen Leonard from comment #17)
> > I think this shouldn't explode if you are not logged in
> 
> Should it 401?

Makes sense to me
Comment 20 Kyle M Hall 2020-10-29 11:51:53 UTC
Created attachment 112662 [details] [review]
Bug 26692: (QA follow-up) Respond with 401 if patron is not logged in
Comment 21 Jonathan Druart 2020-11-05 10:45:19 UTC
Won't it open the door to generate someone else's barcode (easily)?
Comment 22 David Cook 2020-11-05 23:01:37 UTC
(In reply to Jonathan Druart from comment #21)
> Won't it open the door to generate someone else's barcode (easily)?

That's a good point. I hadn't looked at the mechanism.

Perhaps a better barcode image generator would be something like "GET /svc/user/my_barcode" instead of "GET /svc/barcode?barcode=123456"
Comment 23 Kyle M Hall 2020-11-06 13:30:36 UTC
(In reply to Jonathan Druart from comment #21)
> Won't it open the door to generate someone else's barcode (easily)?

I don't see how this is a real issue at all. For example, I already use StoCard on my phone for my library cards. I would easily generate a barcode for another persons library card and use it. Unless library cards are issued with your picture on them, they are not a method of security, they are a method of convenience.
Comment 24 David Cook 2020-11-09 23:15:52 UTC
(In reply to Kyle M Hall from comment #23)
> (In reply to Jonathan Druart from comment #21)
> > Won't it open the door to generate someone else's barcode (easily)?
> 
> I don't see how this is a real issue at all. For example, I already use
> StoCard on my phone for my library cards. I would easily generate a barcode
> for another persons library card and use it. Unless library cards are issued
> with your picture on them, they are not a method of security, they are a
> method of convenience.

I would argue that they are a method of security. Perhaps just not a very secure one. They are roughly the same thing as a (non-encrypted) RFID swipe card, except that the information is transmitted visually rather than by radio waves.

Thinking about this more... you could only generate a barcode for another person's library card if the cardnumbers are predictable (e.g. incremental). 

Looking at the code, there is no validation of any kind, so this service couldn't be used for information discovery or other brute force analysis. It works even if you enter garbage as the input.

I don't really think that this service is optimal, but I think Kyle makes a convincing point in terms of barcode fraud already being easy. (Perhaps we should have more complex barcode schemes in Koha.)
Comment 25 Katrin Fischer 2020-11-10 07:12:27 UTC
Isn't the issue not an organisational instead of a technical one? You should not accept the barcode only if someone has forgotten their card but ask for additional ID to confirm they are who they claim to be.

More difficult for self checks of course. But it just makes it obvious that they are easy to trick now already, especially when working with sequential cardnumbers and barcode readers.

Makes me think that this should have a switch/preference. It might be more suitable for use in some environments than others?
Comment 26 Jonathan Druart 2020-11-10 08:05:16 UTC
I am not feeling comfortable to push this one as it. The code is duplicated from and existing file (a REST API route could have been created), and the use cases of this service is not clear to me.

That's too much for having it part of 20.11.00
Comment 27 David Cook 2020-11-11 01:24:03 UTC
(In reply to Katrin Fischer from comment #25)
> Isn't the issue not an organisational instead of a technical one? You should
> not accept the barcode only if someone has forgotten their card but ask for
> additional ID to confirm they are who they claim to be.
> 
> More difficult for self checks of course. But it just makes it obvious that
> they are easy to trick now already, especially when working with sequential
> cardnumbers and barcode readers.
> 
> Makes me think that this should have a switch/preference. It might be more
> suitable for use in some environments than others?

Actually, I think you make a good point about it being a preference. While I think it's cool that my local public library shows my barcode on my user login page, I suppose not all libraries would want to do that.
Comment 28 David Cook 2022-08-19 00:14:37 UTC Comment hidden (obsolete)
Comment 29 David Cook 2022-08-19 00:19:22 UTC
Honestly, I thought that this had already been pushed to master 😅.

I do reckon it should be a REST API route... probably "GET /api/v1/public/patrons/{patron_id}/barcode"

And then combine it with bug 27825 to determine the type of barcode to generate.

I might end up doing this as a Koha plugin for one of my clients in the meantime.
Comment 30 David Cook 2022-08-25 04:29:26 UTC
Created attachment 139740 [details]
Proposed mobile view
Comment 31 David Cook 2022-08-25 04:29:43 UTC
Created attachment 139741 [details]
Proposed desktop view
Comment 32 David Cook 2022-08-25 04:33:54 UTC
I've put together a Koha plugin that provides the barcode as seen on "Proposed mobile view" and "Proposed desktop view". 

Right now, it's just a proof of concept, and I'm gathering feedback from one of my librarians.

Technically, the plugin just provides the Mojolicious REST API route. Those images are made using hand-made OPACUserJS separate from the plugin. (I figured that was easiest for testing, plus it provides maximum flexibility for libraries.)

I'm sure there are optimizations to make but it's an early draft that I threw together pretty quickly.
Comment 33 David Cook 2022-08-29 01:39:12 UTC
(In reply to Kyle M Hall from comment #0)
> Some libraries would like to add a scannable barcode to the patron self
> service area of the opac for patrons who do not have their library cards
> with them. 

While developing the plugin, I've realized that many libraries might be using laser barcode scanners which are unlikely to work when scanning barcodes on a mobile phone screen...
Comment 34 Kyle M Hall 2022-08-29 10:48:43 UTC
(In reply to David Cook from comment #33)
> (In reply to Kyle M Hall from comment #0)
> > Some libraries would like to add a scannable barcode to the patron self
> > service area of the opac for patrons who do not have their library cards
> > with them. 
> 
> While developing the plugin, I've realized that many libraries might be
> using laser barcode scanners which are unlikely to work when scanning
> barcodes on a mobile phone screen...

Your screenshots look good! As long is the barcode is optional ( and if it's a plugin it definitely is ) I can't see a reason not to have this option for all the libraries using compatible scanners.
Comment 35 David Cook 2022-08-30 07:03:06 UTC
(In reply to Kyle M Hall from comment #34)
> Your screenshots look good! As long is the barcode is optional ( and if it's
> a plugin it definitely is ) I can't see a reason not to have this option for
> all the libraries using compatible scanners.

Yeah, the plugin just gives the API end point. Currently, you have to write your own OpacUserJS to get the image. I figured that would provide max flexibility for libraries. I may end up doing a configuration screen that includes some example JS. 

My library that was interested in this looks like they use an image scanner rather than a laser scanner so it might be all good.

I'll post up my POC plugin here sometime in the next couple days!
Comment 36 David Cook 2022-08-31 02:13:29 UTC
Created attachment 139994 [details]
Koha plugin proof-of-concept

This is still just a proof-of-concept but here is some sample code for OPACUserJS:

$(document).ready(function(){
  let opac_user_views = $("body#opac-user div#opac-user-views");
  if (opac_user_views.length > 0 ){
   	let borrowernumber = window.borrowernumber;
    let url = `${location.origin}/api/v1/contrib/opac_account_barcode/public/patrons/${borrowernumber}/account_barcode/Code39`;
    $.ajax({
    	type: 'HEAD',
      	url: url,
      	success: function(data,status,xhr){
        	opac_user_views.append(`<h2>Your barcode</h2><img src="${url}">`);  
        }
    }); 
  }
});
Comment 37 David Cook 2022-08-31 02:19:10 UTC
Note that you can use any GD::Barcode supported barcode format by changing that last path parameter.

And if you use something that doesn't exist like /api/v1/contrib/opac_account_barcode/public/patrons/57/account_barcode/foo, you'll get this error message:

{"errors":[{"message":"Not in enum list: COOP2of5, Code39, EAN13, EAN8, IATA2of5, ITF, Industrial2of5, Matrix2of5, NW7, QRcode, UPCA, UPCE.","path":"\/barcode_type"}],"status":400}

So that's cool. 

--

Other things to note... you can only get your own barcode. You must be authenticated and you are only authorised to query based on your own patron_id (which is available via Javascript in the OPAC).
Comment 38 David Cook 2022-08-31 02:21:26 UTC
I have a library that is planning to replace physical borrower cards with this barcode that can be scanned from the user's phone, when they log into their Koha OPAC account on their phone.

We haven't gone live yet, but I'm sure that experience will teach me more about anything missing here. 

If it goes well and no one disagrees, we could move the sample OPACUserJS code into the plugin itself (or add plugin hooks for displaying content in the OPAC account pages or whatever).

--

Curious to hear what you think, Kyle!
Comment 39 David Cook 2022-08-31 02:36:19 UTC
It would be cool to do an Etag header using a MD5 hash of the image bytes, but the images are so small that it's probably not worth it.
Comment 40 Kyle M Hall 2022-08-31 09:33:02 UTC
(In reply to David Cook from comment #38)
> I have a library that is planning to replace physical borrower cards with
> this barcode that can be scanned from the user's phone, when they log into
> their Koha OPAC account on their phone.
> 
> We haven't gone live yet, but I'm sure that experience will teach me more
> about anything missing here. 
> 
> If it goes well and no one disagrees, we could move the sample OPACUserJS
> code into the plugin itself (or add plugin hooks for displaying content in
> the OPAC account pages or whatever).
> 
> --
> 
> Curious to hear what you think, Kyle!

Looks great! I can see pros and cons to to having the javascript in the opacjs method of the plugin. One one hand, it makes for a drop-in easy to use plugin for librarians. On the other hand, it does "limit" how it can be displayed if a library wants something different. I honestly think either choice is good. You can always put the javascript in the the documentation.

Do you have this in a public repo yet?
Comment 41 David Cook 2022-09-01 00:58:39 UTC
(In reply to Kyle M Hall from comment #40)
> Looks great! I can see pros and cons to to having the javascript in the
> opacjs method of the plugin. One one hand, it makes for a drop-in easy to
> use plugin for librarians. On the other hand, it does "limit" how it can be
> displayed if a library wants something different. I honestly think either
> choice is good. You can always put the javascript in the the documentation.
> 
> Do you have this in a public repo yet?

We don't have any public repos at the moment, but I'll probably look at doing one at some point. 

For this plugin, it's just a proof of concept, so I figured I'd just upload it here for now. If my 1 client doesn't adopt it, I wouldn't work on it anymore, so probably wouldn't want to advertise it in a public repo at this point.

I think that this code should actually be in core Koha, but I figured a plugin was a good way to rapidly prototype it, and a way to get it out to the client ASAP.
Comment 42 Magnus Enger 2023-07-03 11:56:33 UTC
Has anyone thought more about getting this into Koha?
Comment 43 David Cook 2023-07-04 00:15:37 UTC
(In reply to Magnus Enger from comment #42)
> Has anyone thought more about getting this into Koha?

Nope, but I'm happy for people to take my plugin and adapt it to core Koha. It would be fairly trivial to do. I've just got a mountain of other things to do...
Comment 44 David Cook 2024-03-19 00:04:34 UTC
In the near future, we'll have a large library using a more up-to-date version of the plugin to show an authenticated patron their barcode on the OPAC.

If all goes well, I imagine that I will make an effort to add it to core. 

Right now, I use the API endpoint to generate the image, and then I use OpacUserJS to add a barcode icon to the top navbar and display the barcode in a modal. 

In the core version, I'd want to add the barcode icon and modal via the OPAC templates.
Comment 45 David Cook 2024-03-19 00:58:45 UTC
I also got a question about embedding the barcode in the WELCOME email.

I thought that was pretty interesting. 

This solution wouldn't work in that case.

If we had a $patron->generate_barcode({ type => 'Code39' }) method, we could call that from within Template Toolkit and generate a base64 encoded inline data URI.

I don't know if we'd want to add the base64 encoding to the method or have a separate Template::Toolkit filter for that. 

But that could be interesting.