toegang tot COM-poort "client-pc via ASP.NET website?

[Bob_check_]

Beste leden,

ik heb een redelijk technisch vraagje die hopelijk een positief antwoord oplevert.
Wij hebben hier bij ons bedrijf een scannertje die clienten gebruiken om artikels in te scannen en vervolgens via een off-line applicatie het geheugen van de scanner in te lezen, en door te sturen naar een ftp-site.
Nu is mij gevraagd dit off-line systeem om te zetten in een online-systeem.
Via Visual Studio 2008 ben ik zover gekomen dat als ik lokaal een ASP.NET Development Server draai de scanner goed kan aflezen via een COM-poort op mijn eigen pc. Om deze af te lezen gebruik ik een oude dll van de makers van de scanner, die ik via [DLLImport] gebruik in mijn C# code. Dit werkt alleen op deze manier als ik deze dll in de system32 map van mijn pc kopieer. So far so good.

Nu heb ik deze website gepubliceerd op een echte host, en helaas kreeg ik zoals ik al verwachtte een aantal security errors. Nu is mijn vraag, kan dit uberhaupt? Een com-poort aflezen via een website? Als ik erover google krijg ik gemixte replies, de een zegt het kan niet, de ander zegt het kan wel als je de permissions goed instelt.. Mijn vraag dus, kan het en zo ja, hoe zit het met de permissions? (en met de dll, waar moet die staan)

alvast bedankt, gr. Bob

[Janoz]

Bob_check_ schreef op woensdag 01 juli 2009 @ 12:00:
Nu heb ik deze website gepubliceerd op een echte host, en helaas kreeg ik zoals ik al verwachtte een aantal security errors. Nu is mijn vraag, kan dit uberhaupt? Een com-poort aflezen via een website?

Nee dat kan niet.

De enige manier om dit werkend te krijgen is om op de client een applicatie te installeren die communiceert met de scanner. Vervolgens zou je hem wel, middels bv een ActiveX component, in de website kunnen integreren.

[gorgi_19]

Waarbij je vervolgens wel moet nakijken, mocht het lukken met de clientside oplossing, dat je het binnen het bedrijf voor elkaar krijgt om de ActiveX overal geinstalleerd te krijgen ivm security settngs.

[ Voor 7% gewijzigd door gorgi_19 op 01-07-2009 12:34 ]

[Verwijderd]

Waar hangt die scanner nou precies? Uit je verhaal maak ik op dat die via een COM poort aangesloten is op een centrale computer, maar uit je topictitel lees ik dat je de COM poort van de client PC wilt uitlezen? Of je project kans van slagen heeft hangt heel erg af van het antwoord op die vraag...

[Grijze Vos]

Kijk eens of System.IO.Ports.SerialPort iets voor je kan betekenen. (Dat is, als het probleem hem zit in het feit dat je host geen unmanaged code wil uitvoeren.)

[ Voor 41% gewijzigd door Grijze Vos op 01-07-2009 12:37 ]

[Bob_check_]

Bedankt voor de antwoorden;
ik zal nog even wat extra details geven.
Elke client heeft zijn eigen scanner, en die sluiten ze aan op hun eigen com-poort op hun eigen pc.
De webapplicatie zou daarom dus client-side een com-poort moeten uitlezen.
Ik denk inderdaad dat het probleem de host is, die mijn full-trust security level degradeert tot een medium, waardoor ik geen access meer heb tot com-poorten op de client pc. (of het is toch die unmanaged code, maar ik denk eerder dat de security moeilijk doet over het lezen van de com-poorten dan die dll)

[Janoz]

Bob_check_ schreef op woensdag 01 juli 2009 @ 12:42:
Ik denk inderdaad dat het probleem de host is, die mijn full-trust security level degradeert tot een medium, waardoor ik geen access meer heb tot com-poorten op de client pc. (of het is toch die unmanaged code, maar ik denk eerder dat de security moeilijk doet over het lezen van de com-poorten dan die dll)

Ik denk dat je hier een redelijk fundamentele denkfout maakt. De door jou geschreven ASP.Net code draait helemaal niet bij de client. Je code draait op je eigen server en daarbij wordt wat html gegenereerd die naar de client gestuurd wordt. De enige reden waarom het lokaal wel werkte was omdat de client en server dezelfde pc waren.

Daarnaast zul je het nooit voor elkaar gaan krijgen om de browser zo gek te krijgen dat hij je toegang zal geven tot de compoort. Mocht je een browser vinden die dat wel kan, meld dat dan even, want dan kunnen we er met z'n allen mijlen ver uit de buurt blijven van een dergelijke security ramp.

Je enige oplossing is een clientside component, geinstalleerd op de client zelf.

[creator1988]

Je zou een .Net componentje schrijven, die de data uitleest van de COM poort en deze naar de server stuurt. Dit component kan je vervolgens includen binnen je webpagina als soort ActiveX control. Heb je echter enkel IE ondersteuning.

Met deze zoekopdracht moet je daar genoeg over vinden:
http://www.google.nl/sear...official&client=firefox-a

[R4gnax]

creator1988 schreef op woensdag 01 juli 2009 @ 15:02:
Je zou een .Net componentje schrijven, die de data uitleest van de COM poort en deze naar de server stuurt. Dit component kan je vervolgens includen binnen je webpagina als soort ActiveX control. Heb je echter enkel IE ondersteuning.

Je kunt ook een eenmalig te installeren windows service maken die mbv de HttpListener klasse een zeer simplistiche http server kan draaien op een gegeven poort X die alleen toegang geeft vanaf localhost.

Vervolgens kan de site wanneer deze in de browser geopend is wat javascript starten die een XMLHttpRequest naar http://localhost:X stuurt om te pollen voor scanner gegevens. De info die uit deze request terug komt kan dan met een andere XMLHttpRequest doorgestuurd worden naar een ontvangende webservice die op de centrale server staat.

Als je dit netjes doet dan stop je de COM-poort communicatie in een windows service die onder de system account draait (en dus volledige security rechten zou moeten hebben) en die via een named pipe met een andere service onder een wat meer afgeschermde account communiceert die de HttpListener open zet.

Maakt geen gebruik van ActiveX en werkt dus met elke browser. Vereist alleen dat een administrator eerst die twee services geinstalleerd heeft op de client PC.

offtopic:
Er zou minstens één andere collega Tweaker moeten zijn die dit heel bekend in de oren klinkt, want samen zijn we deze weg ingeslagen voor het bouwen van een web-based updating service voor een stukje custom hardware wat via de COM-poort aangesloten zit.

[ Voor 5% gewijzigd door R4gnax op 01-07-2009 15:20 ]

[Janoz]

R4gnax schreef op woensdag 01 juli 2009 @ 15:19:
[...]


Je kunt ook een eenmalig te installeren windows service maken die mbv de HttpListener klasse een zeer simplistiche http server kan draaien op een gegeven poort X die alleen toegang geeft vanaf localhost.

Vervolgens kan de site wanneer deze in de browser geopend is wat javascript starten die een XMLHttpRequest naar http://localhost:X stuurt om te pollen voor scanner gegevens. De info die uit deze request terug komt kan dan met een andere XMLHttpRequest doorgestuurd worden naar een ontvangende webservice die op de centrale server staat.

Nee, ook dat gaat niet vanwege security beperkingen. Zou dit kunnen dan zou ik door iemand naar een site te lokken, terwijl hij op zijn werk zit, het volledige intranet leeg kunnen trekken zonder dat security er iets aan kan doen.

[Bob_check_]

Die fundamentele denkfout kwam ik toevallig zelf ook net achter, stom van me. Maar goed, ik leer hier weer van, het is de allereerste website die ik maak dus ik gun mezelf nog wat fouten
Dat .NET componentje en dan via ActiveX lijkt me nog de handigste oplossing. Dankje voor je suggestie R4gnax maar wij wilden juist alles via een website doen en geen lokale dingen installeren omdat onze klanten schijnbaar niet de slimste installatiepersonen zijn. Bedankt iedereen in ieder geval!

[Remus]

Ik zou een webservice maken en de client applicatie die de scanner aanstuurt aanpassen (of vervangen) en de resultaten via de webservice verstuurt naar de server. Lijkt mij een stukker makkelijker dan klooien met activex.

Wat is de business reden om het 'online' te doen? Heeft iemand in het management weer gehoord dat als je geen webapplicatie gebruikt je achterloopt? De huidige werking lijkt mij eigenlijk al goed genoeg, wat is de business case om tot vervanging over te gaan?

[Woy]

Bob_check_ schreef op woensdag 01 juli 2009 @ 15:33:
Die fundamentele denkfout kwam ik toevallig zelf ook net achter, stom van me. Maar goed, ik leer hier weer van, het is de allereerste website die ik maak dus ik gun mezelf nog wat fouten
Dat .NET componentje en dan via ActiveX lijkt me nog de handigste oplossing. Dankje voor je suggestie R4gnax maar wij wilden juist alles via een website doen en geen lokale dingen installeren omdat onze klanten schijnbaar niet de slimste installatiepersonen zijn. Bedankt iedereen in ieder geval!

Je zult hoe dan ook wat op de PC's moeten installeren, aangezien een web-app standaard geen rechten heeft om een COM-Poort uit te lezen.

Het echte probleem is dus gewoon dat het mensen niet lukt om te installeren, kun je dat dan niet gewoon afvangen door een simpelere installatie procedure te maken?

Via Click-Once deployment zou het voor gebruikers niet zo moeijlijk moeten zijn. http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx

[Grijze Vos]

Bob_check_ schreef op woensdag 01 juli 2009 @ 15:33:
Die fundamentele denkfout kwam ik toevallig zelf ook net achter, stom van me. Maar goed, ik leer hier weer van, het is de allereerste website die ik maak dus ik gun mezelf nog wat fouten
Dat .NET componentje en dan via ActiveX lijkt me nog de handigste oplossing. Dankje voor je suggestie R4gnax maar wij wilden juist alles via een website doen en geen lokale dingen installeren omdat onze klanten schijnbaar niet de slimste installatiepersonen zijn. Bedankt iedereen in ieder geval!

Ik zou zeer goed nadenken over ActiveX voordat je besluit het te gebruiken. Vziw wordt het gebruik ervan bij IE8 al afgeraden, en is MS van plan in IE9 de hele support te verwijderen.

[creator1988]

Gebruik anders een XBAP applicatie; die kan met ClickOnce dependencies eisen, zoals toegang tot je COM poorten via de security settings.

Installeren van een XBAP app is zo makkelijk als naar de webpagina gaan en op run drukken. Eventueel nog een keer op doorgaan als er wat prerequisites missen.

Werkt overigens prima in zowel Firefox als IE, maar vereist wel Windows. .Net Framework mogelijk ook, maar volgens mij kan hij die ook zelf installeren.


NB. ActiveX hoeft in principe niet moeilijk te zijn. Alleen een boxje van 'wil je dit en dit en vertrouw je het'. Installatie kan via cabinet files, en dat is ook oneclick.

[ Voor 16% gewijzigd door creator1988 op 01-07-2009 16:57 ]

[voodooless]

Ben ik nauw gek of emuleren de meeste barcode scanners gewoon een toetsenbord Zoniet zijn er prima scanners te koop die dat wel kunnen. Lijkt me misschien wel een goedkopere oplossing dan dagen of weken te knutselen voor een software oplossing.

[Grijze Vos]

Janoz schreef op woensdag 01 juli 2009 @ 15:31:
[...]

Nee, ook dat gaat niet vanwege security beperkingen. Zou dit kunnen dan zou ik door iemand naar een site te lokken, terwijl hij op zijn werk zit, het volledige intranet leeg kunnen trekken zonder dat security er iets aan kan doen.

Hmm, ik vraag me af of dat klopt. Ik heb het nog niet getest met een 'echte' remote service. Maar ik kan iig wel van localhost:X naar een webservice op localhost:Y connecten.

Dat zijn -in principe- twee verschillende sites voor een browser, ongeacht dat het alleen een verschil in poort is.

[Woy]

Grijze Vos schreef op woensdag 01 juli 2009 @ 16:53:
[...]

Hmm, ik vraag me af of dat klopt. Ik heb het nog niet getest met een 'echte' remote service. Maar ik kan iig wel van localhost:X naar een weservice op localhost:Y.

Dat zijn -in principe- twee verschillende sites voor een browser, ongeacht dat het alleen een verschil in poort is.

Ja maar een website die op localhost draait heeft misschien wat meer rechten, aangezien die waarschijnlijk in de trusted sites staat.

creator1988 schreef op woensdag 01 juli 2009 @ 16:25:
Gebruik anders een XAML applicatie; die kan met ClickOnce dependencies eisen, zoals toegang tot je COM poorten via de security settings.

Wat heeft XAML met ClickOnce te maken?

[ Voor 82% gewijzigd door Woy op 01-07-2009 16:56 ]

[R4gnax]

Janoz schreef op woensdag 01 juli 2009 @ 15:31:
[...]

Nee, ook dat gaat niet vanwege security beperkingen. Zou dit kunnen dan zou ik door iemand naar een site te lokken, terwijl hij op zijn werk zit, het volledige intranet leeg kunnen trekken zonder dat security er iets aan kan doen.

Er.. Je zou hoogstens de actieve data van de scanner kunnen pollen. HttpListener is een hele simpele klasse die luistert naar TCP/IP berichten in de vorm van het HTTP protocol. Je moet hierna zelf een complete implementatie schrijven van wat er met die berichten gebeurt. Als jij de Listener alleen een simpele string data uit de scanner laat terug geven, dan is dat alles wat iemand te zien zou kunnen krijgen. Niks "intranet leegtrekken".

[supakeen]

voodooless schreef op woensdag 01 juli 2009 @ 16:30:
Ben ik nauw gek of emuleren de meeste barcode scanners gewoon een toetsenbord Zoniet zijn er prima scanners te koop die dat wel kunnen. Lijkt me misschien wel een goedkopere oplossing dan dagen of weken te knutselen voor een software oplossing.

Klopt helemaal, focus op een textveld zetten en vervolgens knop de scanner die het dan automatisch invoert (alsof het een toetsenbord was). Zo heb ik het ook gemaakt

Niks geen applicaties nodig.

[creator1988]

Waar ik XAML zei, bedoel ik XBAP (browser hosted WPF).

[ Voor 24% gewijzigd door creator1988 op 01-07-2009 16:57 ]

[Woy]

creator1988 schreef op woensdag 01 juli 2009 @ 16:57:
Waar ik XAML zei, bedoel ik XBAP (browser hosted WPF).

Ok maar mijn punt is dat je dan net zo goed je client-app via Click-Once kunt deployen. Het hele punt was vanaf het begin dat de installatie procedure blijkbaar te moeilijk was. Aangezien je rechten nodig hebt om de COM-port uit te lezen zal er zowiezo iets van gebruikers-interactie moeten zijn.

Een simpele ClickOnce deployment van je app zou het probleem dan op kunnen lossen.

[Remus]

voodooless schreef op woensdag 01 juli 2009 @ 16:30:
Ben ik nauw gek of emuleren de meeste barcode scanners gewoon een toetsenbord Zoniet zijn er prima scanners te koop die dat wel kunnen. Lijkt me misschien wel een goedkopere oplossing dan dagen of weken te knutselen voor een software oplossing.

Ik las dat hele artikels scannen als het inscannen van artikelen in tijdschriften of kranten (digitaal archief of zo)

[Janoz]

R4gnax schreef op woensdag 01 juli 2009 @ 16:55:
[...]


Er.. Je zou hoogstens de actieve data van de scanner kunnen pollen. HttpListener is een hele simpele klasse die luistert naar TCP/IP berichten in de vorm van het HTTP protocol. Je moet hierna zelf een complete implementatie schrijven van wat er met die berichten gebeurt. Als jij de Listener alleen een simpele string data uit de scanner laat terug geven, dan is dat alles wat iemand te zien zou kunnen krijgen. Niks "intranet leegtrekken".

Het security gat ziet hem niet in je mini http server. Het security gat zit hem er juist in dat een pagina middels javascript zomaar de inhoud van een willekeurige url op kan vragen vanuit de context van de browser. Dat kan iets @ localhost zijn, maar ook http://secret.intranet/bedrijfsgeheimen.

[raptorix]

voodooless schreef op woensdag 01 juli 2009 @ 16:30:
Ben ik nauw gek of emuleren de meeste barcode scanners gewoon een toetsenbord Zoniet zijn er prima scanners te koop die dat wel kunnen. Lijkt me misschien wel een goedkopere oplossing dan dagen of weken te knutselen voor een software oplossing.

Volgens mij wel, ik heb er tenminste in verleden 1 gehad die de serial port gebruikte en idd toetsenbord emuleerde.

[Grijze Vos]

Janoz schreef op woensdag 01 juli 2009 @ 19:27:
[...]

Het security gat ziet hem niet in je mini http server. Het security gat zit hem er juist in dat een pagina middels javascript zomaar de inhoud van een willekeurige url op kan vragen vanuit de context van de browser. Dat kan iets @ localhost zijn, maar ook http://secret.intranet/bedrijfsgeheimen.

Je hebt gelijk. Even snel in de testbank gegooid, komt dit eruit:

code:

uncaught exception: Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)

Een simpele workaround is natuurlijk het draaien van de webservice op de webserver. De app die draait op localhost fungeert dan niet zelf als webservice, maar speelt de data door naar de webservice op de server (push). Diezelfde webservice op de server kan dan de data weer doorgeven naar de ajax client (pull).

[edit]
Hmm, saillant detail. IE7 doet het wel gewoon. (met intranet settings turned off.)

[edit2]
Als ik de settings van medium-high naar high gooi dan blocked ie het wel.

[ Voor 9% gewijzigd door Grijze Vos op 01-07-2009 23:48 ]

[TygeR]

Het lijkt mij ook het makkelijkste om een scanner te pakken die een toetsenbord emuleert (zoals de meeste). Deze geven vaak na een read optioneel ook een enter, en je invoer is compleet. Voordeel hiervan is ook nog dat als een barcode niet leest dat je meteen met je keyboard de invoer kan doen.

[Bob_check_]

Weer iedereen bedankt voor de reacties.
Ik heb net een .NET activeX component gemaakt die als het goed is de scanner moet kunnen aflezen, en het lukt me ook om die in een html-pagina te laten zien (werkt alleen als ik idd de site toevoeg aan trusted sites)
Maar zodra ik de knop indruk krijg ik helaas weer de error dat ik iets probeerde wat niet toegestaan was.
Als ik in de details van de error kijk gaat het fout als hij de serialport wil openen en even checkt of ik daarvoor de permissions heb.. niet dus..
het zal toch echt lastig worden dus om het te doen zonder iets van een lokale installatie.
En suggesties met andere scanners kan helaas niet, want al onze klanten hebben al deze scanners dus dat is volgens mijn manager helaas geen optie.
Iemand nog een idee hoe je de permissie kan krijgen voor het openen van een serialport vanaf een activex component in een webbrowser?

[Janoz]

Grijze Vos schreef op woensdag 01 juli 2009 @ 23:43:
Een simpele workaround is natuurlijk het draaien van de webservice op de webserver. De app die draait op localhost fungeert dan niet zelf als webservice, maar speelt de data door naar de webservice op de server (push). Diezelfde webservice op de server kan dan de data weer doorgeven naar de ajax client (pull).

Euhm.... Je stuurt eerst de gegevens naar de server die ze weer naar de client 'proxy-t' zodat deze ze weer naar de server kan sturen? Klinkt een beetje overengineerd .

[R4gnax]

Janoz schreef op vrijdag 03 juli 2009 @ 09:38:
[...]


Euhm.... Je stuurt eerst de gegevens naar de server die ze weer naar de client 'proxy-t' zodat deze ze weer naar de server kan sturen? Klinkt een beetje overengineerd .

Da's alleen in het geval het een vereiste is dat de user interface voor je applicatie als web app beschikbaar is. Als je applicatie zonder web interface werkt kun je uiteraard direct data pushen naar de webserver zonder dat de browser daar weer opnieuw een pull op los laat.

[Grijze Vos]

Janoz schreef op vrijdag 03 juli 2009 @ 09:38:
[...]


Euhm.... Je stuurt eerst de gegevens naar de server die ze weer naar de client 'proxy-t' zodat deze ze weer naar de server kan sturen? Klinkt een beetje overengineerd .

Als je betere ideeen hebt om een applicatie op een client te laten communiceren met een webpagina die draait in een browser op diezelfde client dan hoor ik ze graag.

[Janoz]

De vraag is of je de resultaten van de scanner clientside wilt behandelen. Het kan natuurlijk ook gewoon dat alles op de server afgehandeld wordt waardoor de output van de scanner niet eerst weer terug naar de client hoeft. Het uiteindelijke doel is immers gewoon om de scandata op de server te krijgen lijkt me.

[Grijze Vos]

In dit specifieke geval zou dat kunnen inderdaad. R4gnax refereerde meer aan een soortgelijk project waar wij op het werk mee bezig zijn, waarbij de browser een status moet geven van wat de com-interface applicatie aan het doen is.

Nu vraag ik me overigens af hoe je com-poort communicatie in de browser wilt doen. Een active-X component is m.i. not done.