Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This is a list of things you, as a developer, should be aware about when working with a solution hosted at Chainbox.
It is probably also good practice to follow this on sites hosted outside Chainbox.
We distinguish between two types of files on the server.
Website (Code, Javascript, CSS, DLL's, Views/templates etc.)
Temporary Data (cache-files, Lucene-indexes etc.)
The website types of files are read-only and can in general only be modified via GIT/Deployment.
If you have a need to store temporary files they should probably be placed in the following directories which are virtual directories mapped to writeable storage.
App_Data/ for content that should be proxied through the application to be accessed.
Beware that the data is not backed up and can disappear during service update/maintanance/website deployment etc. Data stored in these folders are only available to the local server and can't be reached from other instances (load-balanced/fail-over), so in general the website should be the one to populate the data at any time.
Files that should be saved persistently should either be stored in Umbraco-media, chainbox.io CDN or external service of your own choosing.
The master-branch should at any point in time be ready to rolled out on the site / in production.
We might deploy/roll out from master without any warning - i.e. in relation to server updates, moving sites or other maintance related tasks.
If somewhere in the "backend"-code connections to external services are established and they only support the legacy IPv4 protocol, be aware that our servers only have IPv6 addresses and uses NAT64 technology for communicating with the IPv4 internet.
Therefore, make sure not to hardcode IPv4 addresses in the solutions - instead always use DNS resolution to allow NAT64/DNS64 to make the necessary conversions, if you are not able to make the service exposed via IPv6.
Also beware that if the domain is DNSSEC-enabled it can in rare cases cause problems (https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/)
We don't recommend implementing "scheduled tasks" or other long-running requests in the website code - i.e. like generating feeds, sitemaps etc. as webservers are not designed for that.
Doing this can lead to the site being slow, being CPU-throttled, sudden restarts/out of RAM or even unavailable for a period of time.
Long-running tasks are better suited for running in dedicated workers.
Maximum total size of all headers in a response must be no more than 8k.
Session storage is in-process and this not shared among servers, so session should be used in a way that takes this into consideration since requests can hit different instances of the application across servers/nodes.
Solutions are deployed using WebDeploy-method.
You need:
User account on chainbox.io for the organization to which you wish do deploy changes to and be either in the Administrator or Developer group.
To deploy/pull login to your organization on https://my.chainbox.dk/hosting/ and let it guide you to chainbox.io where you enter your credentials.
If you are developer for multiple customers, make sure your are on the right one by selecting it in the upper right corner where available organizations is shown.
Choose Websites on the dashboard
If you have multiple websites select the correct one i the left pane
Click the Deploy button. The result of the operation will be visible in the green area.
With the WebDeploy method a deploy will start a build-job on one of our buildrunner-servers. It will compile the solution and package it using the Package-target in MSBuild. After successfull build, the package will be deployed to the server and replace existing content on the server.
Once you click deploy a deployment-job will be started/put on queue. When the job is finished you will receive an email with the result of the deployment.
Rules of thumb:
Only files included in the project is deployed to server
Don't commit DLL's or any other files generated during compile in GIT. Files in App_Data, resources, and media should typically not be included. They should be uploaded via FTP.
Don't include Umbraco connectionstring, license files etc.
Once you click deploy and get a success response, they deployment-process is triggered but not finished. Only when you get an email the deployment is finished.
To debug problems with deployment or try to see the output you can right-click on the project in Visual Studio and click Publish. Read more here https://msdn.microsoft.com/en-us/library/dd465337%28v=vs.110%29.aspx
Q: My files are not deployed even though they are included in GIT:
This is typically because the files have not been included in the Project-file (csproj).
Q: My module does not work. It works locally:
The prefered way to install Umbraco moduels is via NuGet. Not all modules are available that way. See our FAQ for further instructions in that case.
ℹ Note WebDeploy is the de facto standard deployment-method supported by Microsoft for ASP.NET sites. We recommend reading about WebDeploy in general to become familar with the basic concepts. The information provided in this section is only meant as an overview how WebDeploy works specific to Chainbox Hosting environment and some "rules of thumb".
Hvorvidt en mail havner i spam eller ej er afgjort af modtagerens mailprogram eller mailserver - Når en mail er leveret til modtagerens server har Chainbox som udgangspunkt ingen indflydelse på hvordan den bliver behandlet. Det er sådan set modtageren eller dens udbyder som står for at markere mailen som spam.
Mails kan blive markeret som spam af mange forskellige grunde og det er sjælendt muligt at fastslå præcist hvorfor en mail bliver markeret. Det kan være alt fra at mailen indeholder nogle bestemte ord til hvilken renomḿe ens domæne eller mail-serverens IP på nettet.
Der er dog nogle ting man kan gøre for at minimere risikoen for at mails bliver markeret som spam - F.eks opsætte SPF, DMARC og/eller lign. Kontakt din E-mail leverandør for opsætning heraf.
Vi benytter LetsEncrypt til at udstede TLS/HTTPS certifikater.
Hvis du sætter CAA-records op på dit domæne skal du sørge for at letsencrypt.org værdien er inkluderet for de domæner du har hos os.
F.eks:
0 issue "letsencrypt.org"
ERP database
CMS (Umbraco) database
Website GIT repository
Umbraco-media
Evt. andre data-mapper tilknyttet websitet (App_Data, resources, product-images etc.)
Backups er placeret på to særskilte lokationer
Vi sørger løbende for at holde et passende sikkerhedsniveau i vores systemer og tilpasse/højne niveauet efterhånden som trusselsbilledet og verdenen omkring os ændrer sig.
Alle vores hosting-faciliteter er placeret i danske datacentre der er bygget efter gældende standarder.
Data overføres krypteret når de transporteres over ubeskyttede netværk. Der henvises i øvrigt til jeres Databehandleraftale hvor I bl.a. kan læse mere specifikt hvilke data vi behandler, slettefrister etc.
Du kan ikke få FTP-adgang direkte til Website. Kode-ændringer på sitet skal foregå gennem GIT. Du kan få GIT/udvikler-adgang ved at kontakte os (support@chainbox.dk).
For ældre løsninger der kan du få FTP-adgang til at uploade produkt-billeder ved at kontakte os.
Der skal altid en aktiv handling til for at opdatere en løsning, bl.a. fordi at enkelte opdateringer kan kræve at man manuelt skal håndtere noget manuelt.
Du har selv mulighed for at opdatere din løsning hvis følgende 3 forudsætninger alle er overholdt:
Du er er hostet hos Chainbox
Du har software-opdateringsabonnement/software assurance på løsningen
Du har ingen specialtilpasninger fået lavet på din løsning
Hvis du har fået lavet specialtilpasninger vil der være noget kode som skal kombineres, hvilket kræver nogle andre forudsætninger for at gennemføre en opgradering. Det kræver typisk man er lidt mere teknisk i større eller mindre grad afhængig af kompleksiteten, og det er typsik kun hvis du er udvikler det vil kunne give mening. Der er nogle konkrete kundskaber som typisk er nødvendige:
Være i stand til at bruge GIT - herunder merge-funktionalitet
Kunne Compile løsningen (typisk gennem Microsoft Visual Studio)
Det kræver at du får en udvikler-adgang oprettet for at kunne foretage opdateringerne (Kontakt Chainbox for at blive oprettet)
Filsystemet hvor websitet ligger er Read-Only - ændringer til selve website-koden skal foregå gennem GIT. Få evt. GIT/Udvikler-adgang ved at kontakte os (support@chainbox.dk)
For at oprette et nyt template skal du først oprette filen i GIT (enten manuelt eller gennem din lokale udvikler-Umbraco). Når filen er deployed til serveren, kan du via Umbraco så oprette template.
Ligeledes for at slette et template skal det først slettes i GIT og derefter kan det slettes i Umbraco.
Hvordan overfører jeg dokumenttyper, properties osv. fra lokal Umrbaco ud i Live-Umbraco
Når man udvikler lokalt og laver ændringer til umbraco dokumenttyper, content eller lign. skal disse ud i live/produktion på et tidspunkt.
Der er overordnet set 2 måder at gøre det på:
Udføre ændringerne manuelt (igen) på produktionsmiljøet
Programmatisk oprette/ensure ændringerne f.eks ved opstart af applicationen, så de automatisk vil blive oprettet/ændret hvis de ikke eksisterer.
Hvilken metode der er bedst afhænger af den enkelte situation. Hvis man har flere miljøer (f.eks Dev, Test, Stage og Prod) er den programmatiske ændring nok at foretrække, men normalt er den manuelle tilgang den mest pragmatiske.
Hvordan installerer jeg moduler i Umbraco?
Filsystemet hvor løsningen kører er skrivebeskyttet og mange moduler har brug for at skrive nogle DLL-filer eller lign. til filsystemet under installation.
Hvis installation af moduler eller lign. generer nye filer på filsystemet (udover i Data-mapper) skal disse comittes ind i GIT. Få evt. GIT/Udvikler-adgang ved at kontakte os (support@chainbox.dk)
Processen for at installere et modul eller lign. er således:
Installer modulet på en lokal Umbraco-installation via NuGet
Start løsningen og lad modulet installere sig selv (f.eks generere licens-filer eller lign.)
Commit de nye/ændrede filer installationen har affødt (Husk også at tjekke bin/- og App_Plugins/-mappen for nye dll'er. Husk også at inkludere dem i csproj-projektet, hvis :doc:webdeploy
benyttes (Kun filer som modulet har lagt ind))
Deploy ændringerne til Live-umbraco'en
Gengør evt. installationen af modulet på Live-Umbraco'en hvis den har en sådan
.. tip:: Filer der typisk bliver "glemt" inkluderet i GIT/csproj-filen:
Licens-filer i f.eks bin/
installed
-filer i f.eks App_Plugins/<Plugin>/installed
(f.eks UmbracoForms)
NB: Husk at inkludere dem i BÅDE GIT og i csproj-filen**
Kundeoplysninger sendes ukrypteret, medmindre du har HTTPS/TLS opsat på dit website. Se eventuelt hvordan, du får HTTPS på dit website her
Se HTTPS on Website.
Når dit site har en HTTPS-Gateway foran vil der blive medsendt 3 headers der indikerer den oprindelige request til proxyen.
X-Forwarded-Proto - The protocol used for the request - http or https
X-Forwarded-Port - The port used - 80 for http and 443 for https
X-Forwarded-For - The original IP address by the user. Examples can be: 192.0.2.1 or 2001:db8::1
Du kan få oplyst vores IP-ranges ved at udfylde formularen på https://access.chainbox.dk og angive navn og mail-adresse på den kontaktperson, vi skal skrive til i tilfælde af, at IP-adresserne ændrer sig i fremtiden.
Nej, vi har som udgangspunkt ikke administratorrettigheder til jeres Google Analytics-konto.
Af sikkerhedsmæssige årsager er der sat en Max upload størrelse på 10MB, hvilket skulle dække stortset alle normale behov.
Vores hosting er ikke beregnet til at hoste større filer og vi har ikke mulighed for at justere grænsen uden at det påvirker andre kunder, da du er hostet på et delt miljø.
Såfremt grænsen af den ene eller anden grund ikke er nok for dig er der nogle forskellige muligheder som dog typisk kræver en eller anden forms for tilpasning af løsningen.
Upload via FTP til en speciel mappe
Udvide applikationen til at benytte Streaming - altså uploade filen i små bidder istedet for at uploade hele filen på én gang.
Host filerne på en ekstern CDN eller lign. der er beregnet til at hoste større filer og linke til dem fra webshoppen
Hvad der er muligt i dit tilfælde afhænger helt af scenariet - du er velkommen til at kontakte Chainbox support og høre om vi har et bud på at løse lige præcis dit scenarie.
IDN-domæner - det sig typisk være domæner med f.eks æ, ø å eller andre specialtegn er delvist understøttet.
Er kun understøttet i nyere Webdeploy baserede installationer
Udsendelse af emails (f.eks bestillingsbekræftelser) fra/til IDN-domæner gennem vores SMTP-server er IKKE understøttet.
Denne artikel beskriver hvilke ting man skal være opmærksom på hvis man ønsker et SSL/TLS-certifikat på sin Chainbox Webshop hosted hos Chainbox.
Chainbox benytter såkaldt Virtual Hosting hvor IP-adresser bliver delt mellem flere webshops, således at hostnames afgør hvilken webshop man havner på.
For at TLS-certifikater skal virke med delte ip-adresser skal klienter understørre SNI-standarden. Alle moderne operatirsystemer og browsere understøtter SNI.
Windows XP med Internet Explorer understøtter ikke SNI, så kunder der kører denne kombination af software vil ikke kunne tilgå webshoppen.
De fleste moderne browsere blokerer såkaldt "Mixed Content" - dvs. hvis HTTP-resourcer (javascript, css og lign.) bliver referet fra en side loaded via HTTPS, bliver de ikke loaded.
Hvis dit site nogen steder afhænger af eksterne resource, skal disse resourcer således være tilgeænglige via HTTPS og referencer hertil skal opdateres. Sørger du ikke for det, er der risiko for at HTTP-content ikke vil blive loaded og dele af siden måske ikke virker.
You can get a copy of the latest database snapshot via the Hosting App.
To access, login to your organization on https://my.chainbox.dk/hosting/ and let it guide you to chainbox.io where you enter your credentials.
Make sure you have selected the correct customer in the upper right corner, if you have access to multiple accounts.
Choose the Databases section which lists all databases. The Download Backup button will be available if you are either admin or developer role. If you don't have access, please contact us.
Denne side er henvendt til den/de tekniske person(er) der skal pege dit domæne hen på Chainbox Hosting-miljø i forbindelse med go-live af din nye Chainbox-løsning.
Forudsætningerne for at gå i drift er:
Du skal sørge for du har adgang til at kunne rette DNS-entries for det/de domæner websitet skal publiceres på.
Chainbox er oplyst om hvilke domæner websitet skal lytte/publiceres på og har bekræftet konfigurationen heraf er klar
Chainbox skal have modtaget SMTP-oplysninger til afsendelse af ordrebekræftelser,
Løsningen er færdigtestet og klar til at gå i luften
For de relevante domæner, indsættes/rettes følgende DNS-records til de viste værdier:
Typisk tager det op til et par timer før DNS er slået igennem hele verden rundt afhængig af DNS TTL'en. Det kan anbefales, i god tid (et par dage før), at nedsætte TTL hvis man ønsker at gøre overgangen hvor kunder kan ramme både den nye og gamle løsning så kort som mulig. Så kan den sættes op igen efter go-live.
For at din løsning kan afsende emails såsom bestillingsbekræftelser, password-reset osv. er der brug for en SMTP-konto/adgang. Det er typisk noget din Email-leverandør kan hjælpe med at opsætte.
Kontoen behøver ikke have en decideret "mailbox" tilknyttet - den skal bare kunne afsende mails på vegne af de mail-adresser din løsning bruger som afsender (Den/de mail-adresser der står i Fra/Afsender-feltet på bestillingsbekræftelser etc.)
Vi har typisk brug for følgende oplysninger for at kunne udsende igennem din mail-server
Server/hostname + Portnr.: F.eks smtp.office365.com, port 587
TLS/Kryptering: Hvorvidt der skal bruges TLS/kryptering ved forbindelse
Brugernavn/Password
2-faktor/MFA/2FA skal typisk være slået fra på kontoen.
For optimal sikkerhed, anbefales det at kontoen er dedikeret til brug i din Chainbox-løsning, således at andre systemer ikke deler/bruger samme konto.
Vi kan, som udgangspunkt, først kan aktivere HTTPS/TLS på websitet når DNS'en er ændret + TTL-tid (Dvs. hvis TTL f.eks er på 60 minutter vil der først komme HTTPS på 60 minutter efter DNS er ændret). Alternativt, hvis den eksisterende webhosting-løsning kan lave et redirect som beskrevet her, kan certifikatet udstedes allerede før DNS-ændringen og således vil der være HTTPS på sitet med det samme og undgå at der er et tidspunkt uden HTTPS når du flytter til os.
Opsætningen skal helst laves et par dage før dit domæne skal flyttes. Præcis hvornår det sker er typisk ikke vigtigt, men det bør dog ikke laves for lang tid før flytningen da det kan påvirke dit eksisterende sites HTTPS hvis det er på for længe. Vi anbefaler heller ikke at lave det for kort tid før flytningen hvis der skulle opstå problemer med det, således at det kan sætte hele idriftsættelsen i stå.
Vi anbefaler lige at koordinere med din tilknyttede koordinator/konsulent hos os.
Det der teknisk skal gøres er at dit nuværende domæne skal lave en 302 redirect af adresser til alle URL'er der starter med /.well-known/acme-challenge
til http://acme.hosting.chainbox.dk/.well-known/acme-challenge
. Det er host din nuværende hosting-leverandør opsætningn skal foretages. Hvordan det laves er vidt forskelligt fra leverandør til leverandør.
Når opsætning er fuldført skal du give din koordinator/konsulent hos Chainbox besked - så kan vi tænde for HTTPS.
Følgende er et eksempel på en sådan regel i nginx
location ^~ /.well-known/acme-challenge { return 302 http://acme.hosting.chainbox.dk$request_uri; }
Note Vi bruger ikke wildcard certifikater, så issuewild direktivet er ikke nødvendigt for os.
Note Husk altid at checke Release-notes for dit produkt, om der er sket ændringer der kræver manuel håndtering i forbindelse med opgradering - De findes under dokumentationen det enkelte produkt.
Note Der kan kun opgraderes mellem "minor"-versioner - Dvs. du kan ikke opgradere fra V3 til V4 eller fra V4.0 til V4.1, men du kan godt fra V4.1.3 til V4.1.5
Note Installation uden brug af NuGet er tit behæftet med mange fejlkilder, så det frarådes på det kraftigste.
Note Chainbox Webshop version 4.2 og Webdeploy sammen giver de bedste muligheder for successfuld installation af plugins. Hvis du ikke allerede er på disse teknologier anbefaler vi du kontakter os med henblik på at blive konverteret/opgraderet.
Warning Umbraco moduler er ikke officielt supporteret. De fleste vil virke, men vi stiller ingen garantier for at moduler vil virke sammen med Chainbox Webshop.
Warning Umbraco Forms til Umbraco 7.4 og tidligere (Forms version 4.x-serien) inderholder enten alvorlige sikkerhedshuller eller bugs der får dit site til at gå helt ned hvis du ruller det ud i vores hosting-miljø. Den eneste måde at få Umbraco Forms er ved at opgradere løsningen til minimum Chainbox Webshop 4.2.
Chainbox Replication Klient er et lille program som har til formål t at overførere data fra dit ERP-system ud til Chainbox' Hosting miljø.
Normalvis er det inddelt i to forskellige exports.
Standard Export: Den eksportere ofte ændret ERP data såsom priser, lagertal, produkter og debitorer ud til .
Arkiv Export: Arkivdata såsom Kontoudtog, Ordre-dokumenter osv.
Opgaverne kører i et fastsat tidsinterval som er styreret af Microsoft Task Scheduler. Typisk opsættes de i følgende skema:
Standard Export: kører alle hverdage (mandag til fredag), hver anden time i tidsrummet 06:00 – 20:00.
Arkiv Export: kører alle hverdage en enkelt gang - typisk om natten.
Programmet eksporterer data til og fra Chainbox via HTTPS.
Replikationsklienten skal installeres på en server som altid kører og lever op til følgende krav:
Microsoft-supporteret version af Windows eller Windows Server
Direkte adgang/forbindelse til SQL Serveren hvor ERP data opbevares
Firewall skal tillade at bruge udgående HTTPS (Port 443)
En SQL bruger som skal have Skrive og Læse rettigheder på ERP databasen.
En bruger som replicatorklienten kan køre som, hvis password ikke udløber.
Kombatibelt med .NET 8+