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

+1 for this! :-)

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.

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?

(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 ;)

(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...

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!

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>

Created attachment 112157 [details] [review]
Bug 26692: (QA follow-up) Spelling correction

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

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..

(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!

I think this shouldn't explode if you are not logged in

(In reply to Owen Leonard from comment #17)
> I think this shouldn't explode if you are not logged in

Should it 401?

(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

Created attachment 112662 [details] [review]
Bug 26692: (QA follow-up) Respond with 401 if patron is not logged in

Won't it open the door to generate someone else's barcode (easily)?

(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"

(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.

(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.)

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?

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

(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.

Honestly, I thought that this had already been pushed to master ﷐[U+1F605]﷑.

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.

Created attachment 139740 [details]
Proposed mobile view

Created attachment 139741 [details]
Proposed desktop view

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.

(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...

(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.

(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!

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}">`);  
        }
    }); 
  }
});

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).

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!

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.

(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?

(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.

Has anyone thought more about getting this into Koha?

(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...

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.

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.

We're using JS in OPACUserJS alongside a public report to do this for our clients now.

*** This bug has been marked as a duplicate of bug 26777 ***