Clover: Tabs für den Windows Explorer
Ich glaube schon seit Windows 98 habe ich mich gefragt, warum Microsoft dem Windows Explorer keine Tabs spendiert. Auch Apple bekommt es unter Mac OS nicht hin den Finder Tab-Fähig zu machen. Warum eigentlich nicht?
Clover zeigt wie es gehen könnte. Dieses einfache kleine Tool kombiniert alle Windows Explorer Fenster unter einem Dach und lässt sich dabei so flüssig bedienen, dass es schon fast wie eine native Lösung wirkt.
Auf den ersten Blick fällt sofort auf, dass hier einige Teile vom Google Chrome eingeflossen sind. So gleicht das Look and Feel der Tabs und auch deren Bedienung bis ins Detail dem von Chrome. Alles ist super Flüssig und funktioniert komplett ohne Konfiguration sofort so wie man es gewohnt ist.
So lassen sich neue Tabs mit STRG+T öffnen und mit STRG+TAB durchschalten. Mit einem Doppelklick während man die STRG-Taste gedrückt hält wird der gewählte Ordner in einem neuen Tab geöffnet. Die Tabs selbst integrieren sich in die Titelleiste des Fensters und verbrauchen so gut wie keinen Platz.
Optional kann man auch noch (wie auch im Chrome) eine Lesezeichenleiste einblenden lassen, in der man seine Lieblingsordner speichern kann. Ich finde aber, dass es die Optik etwas stört.
Das Icon des Programms könnt ihr ebenfalls verändern, wenn euch das Kleeblatt nicht zusagt. Eine Anleitung dafür gibts auf der Homepage des Entwicklers.
Office oder Windows Lizenzschluessel aus einer anderen Windows Installation wiederherstellen
Die Beiträge hier im Blog darüber wie man den Office und Windows Key aus der Registry lesen kann erfreuen sich sich großer Beliebtheit, weswegen ich auch das kleine Tool Get My Keys Back erstellt habe.
Doch erreichen mich immer mehr Mails mit der Frage danach wie man den Schlüssel wiederherstellen kann wenn man Windows neuinstalliert hat, wenn die Installation beschädigt ist oder wenn die Daten auf einer anderen Festplatte liegen.
Manchmal passiert es auch, dass Get My Keys Back es nicht schafft den Office Key auszulesen, obwohl Office installiert ist. Mit dieser Anleitung könnt ihr es nun manuell machen.
Get My Keys Back funktioniert hier natürlich nicht, da es nur in der gerade aktiven Registry nach dem Schlüssel sucht. Ich habe mich mit dieser Frage etwas beschäftigt und hoffe euch mit diesem Beitrag eine Hilfestellung geben zu können.
SerialDecoder
Um es euch möglichst einfach zu machen habe ich das kleine Tool "SerialDecoder" geschrieben, das ihr ab sofort auf meiner Homepage herunterladen und testen könnt. Dieses Programm benötigt aber auch die Werte aus der Registry, und zwar aus der Registry die nicht mehr aktiv ist, z.B. die auf eurer anderen Festplatte von der ihr die Seriennummer haben wollt.
Der Prozess den Schlüssel zu beschaffen unterteilt sich in drei Schritte:
- Beschaffen der Registrydaten von der alten Festplatte
- Beschaffen der Daten aus der alten Registry
- Umwandeln der Daten in den schlüssel
An euch liegt es nun diese Daten aus der anderen Festplatte zu lesen. Dies ist relativ einfach, folgt einfach dieser kleinen Anleitung:
- Schließt die alte Festplatte an und öffnet diese im Windows Explorer
- Navigiert dort in das Verzeichnis: \Windows\System32\config
- Kopiert aus diesem Verzeichnis die Datei "SOFTWARE" in ein Verzeichnis auf eurer aktiven Festplatte.
- Startet nun die Registry, indem ihr die Windows-Taste und die R-Taste gleichzeitig drückt.
- In das nun erscheinende Fenster tippt ihr "regedit" ohne "" und drückt auf OK.
- Im Regestrierungseditor klickt ihr auf Datei und dann auf Struktur laden... (Tipp: Struktur laden ist nur anklickbar, wenn ihr den passenden Knoten (HKEY_LOCAL_MACHINE) auswählt)
- Wählt nun die eben kopierte Datei "SOFTWARE" aus.
- Gebt nun einen schlüssigen Namen ein z.B. "Alte Festplatte"
- Nun wird diese Registry Datei geladen und ihr seht sie in eurem Registry-Explorer. Öffnet diese nun.
Schritt 2: Auslesen der Schlüssel
Navigiert in der nun geladenen Struktur an folgende Stellen um die Keys zu erhalten:
Office auf 32-Bit Systemen:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office
Office auf 64-Bit Systemen:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office
Bei Office wählt ihr nun eure Version, wobei
- 11 = 2003
- 12 = 2007
- 14 = 2010
- 15 = 2013
Im Normalfall solltet ihr einfach die größte Zahl auswählen. In diesem Verzeichnis wählt ihr nun den Ordner Registration. Hier werden wahrscheinlich einige Ordner mit sehr kryptischen Namen sein, sucht den wo der Schlüssel namens "DigitalProductId" auftaucht:
Probiert die Ordner einfach durch, der richtige Ordner ist meist der mit den meisten Schlüsseln.
Klickt nun mit der rechten Maustaste auf den passenden Ordner und wählt "Exportieren". Speichert die Datei nun ab.
(Falls ihr nur diesen Key benötigt springt zum Schritt 3 Schlüssel umwandeln weiter unten)
Windows Key:
SOFTWARE\Microsoft\Windows NT\CurrentVersion
Hier seht ihr nun einige Schlüssel, unter Anderem auch den DigitalProductId, der uns interessiert (Beispiel für Windows Key).
Klickt nun mir der rechten Maustaste auf den Ordner "CurrentVersion" in der rechten Übersicht und wählt "Exportieren" und speichert die Daten an einem für euch leicht wieder findbaren Ort.
Schritt 3: Schlüssel umwandeln
Da ihr nun die Daten zum Windows und/oder zum Office Key gesichert habt könnt ihr diese nun nutzen um den Key wiederherzustellen.
Nun müsst ihr mein kleines Tool namens "SerialDecoder" von meiner Homepage laden und starten.
Öffnet nun eine der Dateien die ihr eben durch das Exportieren erstellt habt in einem Texteditor:
Sucht den Eintrag namens "DigitalProductId" und markiert alle Zeichen ab hex: bis zum Ende des Eintrags. Ein Beispiel wie es aussehen kann seht ihr in dem Oberen Bild. Wichtig: Markiert wirklich nur diesen Bereich ohne das hex: und ohne den Eigenschaften-Namen, wirklich genauso wie es oben in dem Bild gezeigt ist.
Das Bild zeigt ein Beispiel für einen Windows Key, die Office-Keys sind für gewöhnlich länger, lasst euch davon also nicht verwirren.
Kopiert diesen Markierten Text nun in die Zwischenablage und fügt diesen Text nun im SerialDecoder ein:
Nicht erschrecken: Der SerialDecoder entfernt alle unnötigen Zeichen wie Leerzeichen und Zeilenumbrüche.
Klickt nun auf "Schlüssel auslesen" unten im Fenster und wählt die Art von Schlüssel die ihr auslesen wollt. (Hier Windows Key)
Der SerialDecoder wandelt nun die Daten in euren Key um.
ACHTUNG: SerialDecoder kann nicht feststellen ob ihr die Daten korrekt eingefügt habt, also ob ihr vielleicht zuviel kopiert habt oder zu wenig. Deswegen achtet sehr genau was ihr reinkopiert! Des Weiteren kann ich natürlich nicht für die Korrektheit des ausgelesenen Keys garantieren. Das Programm ist grad in der Testphase und lebt momentan von eurem Feedback, damit ich es weiter verbessern kann.
SSL Teil 4: Serverseitige Authentifizierung mit Java
Nachdem wir in den letzen Teilen mehr die Theorie durchgenommen haben, möchte ich jetzt zu dem praktischen Teil kommen und euch zeigen wie man diese Theorie in Code umsetzen kann am Beispiel Java. (.NET wird auch noch folgen)
Wir wollen einfach einsteigen und implementieren erst mal nur die eine Serverseitige Authentifizierung, also muss der Server sich uns gegenüber ausweisen und wir sind in der Pflicht sein Zertifikat anzunehmen oder abzulehnen.
Wie in Teil 1 erklärt benötigen wir also zunächst einen Ort wo wir die Zertifikate sichern, denen wir vertrauen. Hier können wir (da wir in Java unterwegs sind) nicht die Windows-eigenen nehmen sondern müssen die so genannten Keystores von Java Nutzen.
Ein Keystore, wie der Name schon sagt ist nichts anderes als ein Speicher für Zertifikate. Wenn ihr Java installiert dann legt Java bereits einen Keystore für euch an, diesen findet ihr dann in eurem Java Verzeichnis Java\jre6\lib\security\cacerts die Datei „cacerts“ enthält hier bereits ähnlich wie bei Windows bereits die CA-Zertifikate von den großen Zertifizierungsstellen.
Es wir desweiterhin in Java unterschieden zwischen Keystore und Truststore, beides sind im Grunde Keystores und unterscheiden sich nur im Namen und in ihrem Inhalt. Eine einzige Datei kann auch beide beinhalten, ist aber eher unüblich, da man die eigenen (privaten) Zertifikate von den CA-Zertifikaten separieren will.
So enthalten die Keystores für gewöhnlich die eigenen Privaten Schlüssel und die eigenen von anderen CAs signierte Zertifikate, die bei Verbindungen als Serverzertifikate (Public Keys) genutzt werden. Der Truststore ist das Gegenstück und enthält die Zertifikate denen man vertraut. So müssen wir die Zertifikate die wir vom Server beim Verbindungsaufbau erhalten gegen einen Truststore prüfen.
Fangen wir mit unserem Code an, wir wollen einen Client erstellen, der eine Socket-basierte Verbindung zu einem Server über SSL aufbaut und das vom Server zurückgegebene Zertifikat prüft.
Java ist auf diesem Gebiet sehr entgegenkommend und bietet für fast alle Anwendungsfälle fertige APIs und Klassen die uns fast die ganze Arbeit abnehmen.
Um den Prozess besser aufzeigen zu können schreiben wir uns eine Eigene SSLSocketFactory die für uns den Aufbau der Verbindung übernimmt und unserem Programm im Prinzip ein fertiges Socket liefert.
Dazu erstellen wir eine neue Klasse und lassen diese von SSLSocketFactory erben. Da das eine abstrakte Klasse ist müssen eir einige Methoden implementieren. Wenn das erledigt ist sieht unsere Klasse schon so aus:
/** * Stellt eine SSLSocketFactory bereit die einen angegebenen TrustStore nutzt * @author Sebastian Gross */ public class ServerSSLAuthSocketFactory extends SSLSocketFactory{ @Override public String[] getDefaultCipherSuites() { } @Override public String[] getSupportedCipherSuites() { } @Override public Socket createSocket(Socket socket, String string, int i, boolean bln) throws IOException { } @Override public Socket createSocket(String destinationAddress, int destinationPort) throws IOException, UnknownHostException { } @Override public Socket createSocket(String string, int i, InetAddress ia, int i1) throws IOException, UnknownHostException { } @Override public Socket createSocket(InetAddress ia, int i) throws IOException { } @Override public Socket createSocket(InetAddress ia, int i, InetAddress ia1, int i1) throws IOException { } }Nun müssen wir diesen Methoden Leben einhauchen, aber keine Angst das ist nicht so schlimm wie es aussieht, denn die einzige Änderung die wir machen müssen ist es der SSLSocktFactory beizubringen mit unserem Truststore zu arbeiten, der Rest der Funktionalität soll unberührt bleiben.
Fügen wir also einen Konstruktor zu unserer Klasse hinzu der das Initialisieren unserer Internen SSLSocketFactory mit unserem Truststore übernimmt.
/** Delegate {@link SSLSocketFactory}. */ private transient SSLSocketFactory factory; private File caFile; private KeyStore ks; private SSLContext context; private TrustManagerFactory tmf; private X509TrustManager defTrustManager; private SavingTrustManager tm; /** * Neue Truststore-basierte SSL-SocketFactory * @param truststoreLocation Vollqualifizierter Pfad zum Truststore oder leer lassen für Java-Default-Truststore * @param truststorePass Passwort für den Truststore. Wenn leer wird "changeit" ala Passwort benutzt. */ public ServerSSLAuthSocketFactory(String truststoreLocation, String truststorePass){ super(); //Wenn ein Pfad zum TrustStore angegeben wurde diesen benutzen if(!truststoreLocation.isEmpty()){ caFile = new File(truststoreLocation); }else{ //Pfad zum default Java TrustStore finden caFile = new File("cacerts"); if (!caFile.exists() || !caFile.isFile()) { char SEP = File.separatorChar; File dir = new File(System.getProperty("java.home") + SEP + "lib" + SEP + "security"); caFile = new File(dir, "cacerts"); if (!caFile.exists() || !caFile.isFile()) { caFile = new File(dir, "cacerts"); } } } //Prüfen, ob ein TrustStore Password angegeben wurde String truststorePassword = truststorePass.isEmpty() ? "changeit" : truststorePass; //TrustStore öffnen try { InputStream in = new FileInputStream(caFile); ks = KeyStore.getInstance(KeyStore.getDefaultType()); ks.load(in, truststorePassword.toCharArray()); in.close(); } catch (KeyStoreException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (NoSuchAlgorithmException ex){ Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (CertificateException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (FileNotFoundException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); }catch (IOException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } try { context = SSLContext.getInstance("TLS"); tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); tmf.init(ks); defTrustManager = (X509TrustManager)tmf.getTrustManagers()[0]; context.init(null, new TrustManager[] {defTrustManager}, null); factory = context.getSocketFactory(); } catch (NoSuchAlgorithmException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (KeyStoreException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (KeyManagementException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } }Das sieht auf den ersten Blick recht komplex aus, ist aber im Grunde recht simpel.
- In den Zeilen 23 - 28 prüfen wir ob der Konstruktor einen Pfad zu einem Truststore übergeben bekommen hat, und wenn dies nicht der Fall ist, wird der Pfad zu dem Standard-Java-Truststore in eurem JRE-Verzeichnis ermittelt.
- Direkt danach in Zeile 41 prüfen wir ob ein Passwort übergeben wurde. Wenn keins übergeben wurde wird "changeit" genutzt. "changeit" ist das Defaultpasswort für den Standard-Java-Truststore.
- In Zeile 45 - 48 öffnen wir den Keystore und laden dessen Inhalt in unsere Kokale KeyStore Variable.
- Das Wichtigste geschieht nun in Zeile 67 - 72 hier holen wir uns einen Verweis auf den SSLContext (67) und erstellen uns mit Hilfe unseres KeyStores einene TrustManagerFactory(68-69). Anschließend lassen wir die TrustManagerFactory für uns einen neuen X509TrustManager "produzieren" der dann den Verweis auf unseren eigenen Keystore trägt. (70)
- Nun sagen wir dem SSLContext, dass es unseren Trustmanager nutzen soll (71) für die darüber laufende Verbindungen und erstellen uns eine SSLSocketFactory (72)
Nun haben wir intern eine SocketFactory, die unseren eigenen (über den Konstruktor angegebenen) Keystore nutzt. Der Rest der Klasse die wir erstellt haben dient hierbei eigentlich nur als Wrapper und Durchreiche, der Wichtigste Teil war der Konstruktor.
Die restlichen Methoden können nun also alle Anfragen direkt an die produzierte SSLSocketFactory weiterleiten. So sieht dann die fertige Klasse aus:
import java.io.File; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.IOException; import java.io.InputStream; import java.net.InetAddress; import java.net.Socket; import java.net.UnknownHostException; import java.security.KeyManagementException; import java.security.KeyStore; import java.security.KeyStoreException; import java.security.NoSuchAlgorithmException; import java.security.cert.CertificateException; import java.security.cert.X509Certificate; import java.util.logging.Level; import java.util.logging.Logger; import javax.net.ssl.SSLContext; import javax.net.ssl.SSLSocket; import javax.net.ssl.SSLSocketFactory; import javax.net.ssl.TrustManager; import javax.net.ssl.TrustManagerFactory; import javax.net.ssl.X509TrustManager; /** * Stellt eine SSLSocketFactory bereit die einen angegebenen TrustStore nutzt * @author Sebastian Gross */ public class ServerSSLAuthSocketFactory extends SSLSocketFactory{ /** Delegate {@link SSLSocketFactory}. */ private transient SSLSocketFactory factory; private File caFile; private KeyStore ks; private SSLContext context; private TrustManagerFactory tmf; private X509TrustManager defTrustManager; private SavingTrustManager tm; /** * Neue Truststore-basierte SSL-SocketFactory * @param truststoreLocation Vollqualifizierter Pfad zum * Truststore oder leer lassen für Java-Default-Truststore * @param truststorePass Passwort für den Truststore. * Wenn leer wird "changeit" ala Passwort benutzt. */ public ServerSSLAuthSocketFactory(String truststoreLocation, String truststorePass){ super(); //Wenn ein Pfad zum TrustStore angegeben wurde diesen benutzen if(!truststoreLocation.isEmpty()){ caFile = new File(truststoreLocation); }else{ //Pfad zum default Java TrustStore finden caFile = new File("cacerts"); if (!caFile.exists() || !caFile.isFile()) { char SEP = File.separatorChar; File dir = new File(System.getProperty("java.home") + SEP + "lib" + SEP + "security"); caFile = new File(dir, "cacerts"); if (!caFile.exists() || !caFile.isFile()) { caFile = new File(dir, "cacerts"); } } } //Prüfen, ob ein TrustStore Password angegeben wurde String truststorePassword = truststorePass.isEmpty() ? "changeit" : truststorePass; //TrustStore öffnen try { InputStream in = new FileInputStream(caFile); ks = KeyStore.getInstance(KeyStore.getDefaultType()); ks.load(in, truststorePassword.toCharArray()); in.close(); } catch (KeyStoreException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (NoSuchAlgorithmException ex){ Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (CertificateException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (FileNotFoundException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); }catch (IOException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } try { context = SSLContext.getInstance("TLS"); tmf = TrustManagerFactory.getInstance(TrustManagerFactory .getDefaultAlgorithm()); tmf.init(ks); defTrustManager = (X509TrustManager)tmf.getTrustManagers()[0]; context.init(null, new TrustManager[] {defTrustManager}, null); factory = context.getSocketFactory(); } catch (NoSuchAlgorithmException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (KeyStoreException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } catch (KeyManagementException ex) { Logger.getLogger(ServerSSLAuthSocketFactory.class.getName()) .log(Level.SEVERE, null, ex); } } @Override public String[] getDefaultCipherSuites() { return factory.getDefaultCipherSuites(); } @Override public String[] getSupportedCipherSuites() { return factory.getSupportedCipherSuites(); } @Override public Socket createSocket(Socket socket, String string, int i, boolean bln) throws IOException { return factory.createSocket(socket, string, i, bln); } @Override public Socket createSocket(String destinationAddress, int destinationPort) throws IOException, UnknownHostException { return (SSLSocket)factory.createSocket(destinationAddress, destinationPort); } @Override public Socket createSocket(String string, int i, InetAddress ia, int i1) throws IOException, UnknownHostException { return factory.createSocket(string, i, ia, i1); } @Override public Socket createSocket(InetAddress ia, int i) throws IOException { return factory.createSocket(ia, i); } @Override public Socket createSocket(InetAddress ia, int i, InetAddress ia1, int i1) throws IOException { return factory.createSocket(ia, i, ia1, i1); } }Da wir nun eine Factory haben die uns Sockets liefert, die auf unseren Truststore zugreift, können wir diese nun nutzen um eine Verbindung zu SSL Servern aufzubauen. Das Schöne hierbei ist, dass Java an sehr vielen Stellen SocketFactories nutzt, so können wir fast in allen Szenarien unsere Klasse einsetzen.
So können wir unsere SSLFactory nun ganz simpel testen:
public static void main (String [] args) throws IOException{ int port = 443; // default https port String host = "httpsurl"; try { SSLSocketFactory factory = (SSLSocketFactory) new ServerSSLAuthSocketFactory("",""); SSLSocket socket = (SSLSocket) factory.createSocket(host, port); // enable all the suites String[] supported = socket.getSupportedCipherSuites(); socket.setEnabledCipherSuites(supported); Writer out = new OutputStreamWriter(socket.getOutputStream()); // https requires the full URL in the GET line out.write("GET https://" + host + "/ HTTP/1.1\r\n"); out.write("Host: " + host + "\r\n"); out.write("\r\n"); out.flush(); // read response BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream())); // read the header String s; while (!(s = in.readLine()).equals("")) { System.out.println(s); } System.out.println(); // read the length String contentLength = in.readLine(); int length = Integer.MAX_VALUE; try { length = Integer.parseInt(contentLength.trim(), 16); } catch (NumberFormatException ex) { // This server doesn't send the content-length // in the first line of the response body } System.out.println(contentLength); int c; int i = 0; while ((c = in.read()) != -1 && i++ < length) { System.out.write(c); } System.out.println(); out.close(); in.close(); socket.close(); } catch (IOException ex) { System.err.println(ex); } }Tragt in Zeile 4 einfach den gewünschten SSL-Host ein wie z.B. Google oder Facebook und startet das kleine Programm. Falls ihr keine Parameter beim Erzeugen der Factory (Zeile 7 und 8) angegeben habt solltet ihr auch keine Probleme beim Verbinden haben und wenn das Programm durchgelaufen ist seht ihr die Antwort des Servers im HTML Format.
Falls ihr doch einen eigenen Truststore eingetragen habt müsst ihr sicherstellen, dass dieser den Public Key des Servers zu dem ihr euch verbinden wollt beinhaltet, sonst wird die Verbindung nicht erfolgen.
Teil 1: Serverseitige Authentifizierung und Zertifikate
Teil 2: Beidseitige Authentifizierung
Teil 3: Der SSL Handshake
Teil 4: Serverseitige Authentifizierung mit Java
SSL Teil 1: Serverseitige Authentifizierung und Zertifikate
SSL ist aktiv
SSL (Secure Socket Layer) sollte wohl den meisten ein Begriff sein, das ist dieses lustige kleine "s" was manchmal hinter dem "http" in der Adresszeile des Browsers auftaucht (siehe Bild). In dieser Serie möchte ich euch erklären wie SSL in der Theorie funktioniert und wie ihr es in euren Applikationen nutzen könnt.
Viele Bekannte Webportale wie Facebook und Google bieten alle ihre Dienste inzwischen komplett über SSL an. Wenn ihr diese Technologie nutzen wollt, müsst ihr verstehen wie diese Funktioniert und was da eigentlich im Hintergrund abläuft.
Dieses kleine "s" hat eine große Wirkung und sorgt dafür, dass die gesamte Kommunikation mit dem Server in verschlüsselter Form abläuft und niemand sehen kann was ihr da so treibt.
In 99% der Fälle sprechen wir hier über SSL über Serverseitige Authentifizierung, was soviel heißt wie der Server muss uns beweisen, dass er der ist für den er sich ausgibt. So wie wir unseren Ausweis vorzeigen müssen wenn wir ein Paket bei der Post abholen müssen weil der Postbote wiedermal zu faul war zu klingeln... Wir müssen der Post beweisen, dass wir der sind für den wir uns ausgeben.
Wie weist sich der Server denn nun aus? Einen Ausweis hat er nicht, aber er hat etwas sehr ähnliches, nämlich ein Zertifikat, das von einer dritten Stelle, nämlich einer CA (Certificate Authority - auf deutsch Zertifizierungsstelle) signiert wurde.
Wenn wir das auf unser Ausweisbeispiel anwenden sieht es ca so aus: Jeder kann sich ein Blatt Papier mit einem Foto drucken wo sein Name draufsteht, aber euer Paket bei der Post werdet ihr damit nicht bekommen, da die Post der Herkunft des "Ausweises" nicht traut, es muss also von anderen Person (der die Post vertraut), die nicht ihr selbst seid, bestätigt werden, dass das wirklich ein echter Ausweis ist und dass das wirklich ihr seid. Im Falle eines Ausweises würde das wohl das Einwohnermeldeamt machen o.ä. diese würden euch einen Ausweis austellen dem andere vertrauen, da sie wissen, dass es aus einer vertrauenswürdigen Quelle kommt.
Wenn ihr euch also zu einem Server verbindet, der SSL nutzen will wird dieser euch also zunächst sein Zertifikat senden (seinen Ausweis) und nun seid ihr in der Pflicht zu entscheiden, ob ihr diesem Zertifikat (und somit dem Server) vertraut oder nicht.
Die (Vertrauens)-Prüfung übernimmt für euch meistens der Browser selbst. Jeder Browser kommt von Haus aus mit einer Liste von CAs denen er blind vertraut. Diese Liste könnt ihr auch einsehen, sie ist häufig irgendwo in den Einstellungen des Browsers vergraben. Im Firefox findet ihr diese unter Einstellungen -> Erweitert -> Verschlüsselung ->Zertifikate anzeigen -> Zertifizierungstellen. Das sieht dann ca so aus:
Das bedeutet, wenn ein Server dem Browser ein Zertifikat schickt, dass von einer dieser CAs signiert wurde, vertraut der Browser dem Server und baut die Verbindung zu ihm auf.
Was passiert denn nun wenn der Server uns ein unsigniertes Zertifikat schickt, oder ein Zertifikat dass von einer CA signiert wurde die dem Browser unbekannt ist?
Dann wird uns der Browser fragen, ob wir uns wirklich sicher sind, dass wir uns sicher sind, dass wir diese Seite wirklich aufrufen wollen. Dieses Fenster habt ihr (im FireFox) vielleicht auch schon gesehen:
Nun müsst ihr also selbst entscheiden, ob ihr diesem Zertifikat vertraut. Hier sollte man aufpassen, denn wenn es um wichtige Sachen geht wie Online Banking sollte man von dieser Seite die Finger lasse, da es sich eventuell um ein Phishing versuch handeln könnte - diese Meldung ist niemals ein gutes Zeichen.
Wenn ihr hier das Zertifikat also akzeptiert, merkt der FireFox sich das und fragt bei der nächsten Verbindung nicht mehr nach da es für ihn ab nun ein vertrauenswürdiges Zertifikat ist.
Aber nicht nur die Browser haben einen solchen Zertifikate-Speicher, das Betriebssystem selbst hat ebenfalls eine Liste mit CAs denen es Vertrauen schänkt. Diese Liste kann in den Systemeinstellungen gefunden werden und wird sich häufig mit der des Browsers großenteils überschneiden. Unter Windows findest ihr diese unter Systemsteuerung -> Netzwerk und Internet ->Internetoptionen -> Inhalte -> Zertifikate -> Vertrauenswürdige Stammzertifizierungsstellen
Was steht eigentlich in so einem Zertifikat? Gucken wir doch mal rein:
Jedes Zertifikat enthält diese Informationen:
- Anwendung (Ist es ein Server oder ein Clientzertifikat?)
- Wer hat das Zertifikat ausgestellt?
- Für wen wurde dieses Zertifikat ausgestellt
- Wielang ist das Zertifikat gültig?
- Die Signierungskette aller CAs die dieses Zertifikat signiert haben
An Hand dieser Informationen wird entschieden, ob das Zertifikat akzeptiert wird oder nicht.
Zertifikate sind hierbei nichts besonderes, da jeder sich selbst Zertifikate ausstellen kann, es gibts dutzende Tools im Netz die euch Zertifikate generieren können, wie z.B. das kleine Javaprogramm "keytool" dass automatisch mit einem Java SDK mitinstalliert wird. Das Wichtige an einem Zertifikat ist immer seine Signatur, denn erst diese macht ein Zertifikat wertvoll und für andere Vertrauenswürdig.
Teil 1: Serverseitige Authentifizierung und Zertifikate
Teil 2: Beidseitige Authentifizierung
Teil 3: Der SSL Handshake
Teil 4: Serverseitige Authentifizierung mit Java
Jede Adventswoche ein Microsoft Press E-Book gratis
Wie auch letztes Jahr verschenkt Microsoft Press auch dieses Jahr wieder E-Books. Dabei gibt es jede Adventswoche ein neues E-Book, dass kostenlos heruntergeladen werden kann.
Den Anfang macht heute das Windows 7 Home Premium "Maxibuch", das ca 1000 Seiten umfasst.
Microsoft Windows 7 wird mit "Microsoft Windows 7 Home Premium - Das MAXIBUCH" erst richtig schön. Damit Sie die vielen Möglichkeiten entdecken und verstehen, hat sich das Autorenteam lange mit Windows 7 Home Premium auseinandergesetzt.
Sie erhalten von uns kostenlos eine gelungene und sehr ausführliche Windows 7-Beschreibung!
Wissen aus erster Hand auf über 1.000 Seiten! (PDF, 80.2 MB)
Rechnen Sie unbedingt auch mit Tipps, wie Sie schneller, einfacher und sicherer arbeiten - und Spaß bekommen.
Wer Interesse hat muss lediglich seine E-Mail Adresse auf der Aktionsseite eintragen und bekommt einen Download-link zugeschickt.
Nachtrag:
Anscheinend sind momentan die Server ziemlich ausgelastet:
Entschuldigung.
Unser Downloadserver ist überlastet.
Bitte Versuchen Sie es in wenigen Minuten noch einmal.
Vielen Dank für Ihre Verständnis.
Aber zum Glück hat man die Ganze Woche Zeit um es herunterzuladen.
Ein Steiniger Weg: SuperDrive gegen SSD eintauschen
Diejenigen von euch die mir bei Twitter folgen haben es wohl schon mitbekommen, dass ich das DVD Laufwerk meines MacBooks (late 2008) genannt SuperDrive gegen eine SSD eintauschen wollte.
Warum der Stress?
Also ich weiß nicht wie es bei euch ist, aber ich nutze das im MacBook verbaute DVD Laufwerk so gut wie nie! Ich habe damit mal Windows installiert, oder auch mal Mac OS, ein mal habe ich sogar mal ein paar Dateien auf eine DVD gebrannt, aber mehr war es auch wirklich nicht.
So gut wie alle Daten die auf meinen Rechner kommen tuen es entweder übers Internet oder über einen USB-Stick. Mal ernsthaft wie oft verwendet ihr eure DVD Laufwerke?
Da ich schon seit längerem mit dem Gedanken Spiele mir eine SSD anzuschaffen, aber immer gezögert habe, da diese recht teuer sind und wenig Speicherplatz bieten als das man sie gegen die verbaute Festplatte tauschen könnte, habe ich mir gedacht, hey, warum nicht den Teil ausbauen, den du sowieso nicht nutzt?
Erste Schwierigkeiten
Wie ihr euch sicher denken könnt kann man ein ganzes DVD Laufwerk nicht einfach gegen eine viel kleinere SSD tauschen. Erstens ist da die Größe die nicht passt und zweitens auch der Anschluss, der ein etwas kleinerer ist am Laufwerk.
Ein Adapter muss her.
Meine ersten Suchversuche führten mich zum Optibay von MCE. Das hat mich wirklich aus den Socken genauen! Da soll man wirklich für ein Stück Allu mit einem, SATA Adapter drauf $100 plus Versand und Zoll bezahlen. – Nein danke!
Kurz darauf habe ich bei eBay ein “Konkurrenz”-Produkt gefunden, dass nicht nur Optisch besser aussah, sondern mir auch noch preislich besser gefiel (13€ inkl Versand).
Knapp drei Wochen später kam das Päckchen dann auch bei mir an:
Die SSD
Man kann wirklich viel Zeit in die Suche nach der “richtigen” SSD investieren, so war ich @Twittlor (Marek) wirklich dankbar für seinen Tipp, der mich zur OCZ OCZSSD2-2VTXE60G 60GB führte.
Nach einer kleinen Google Recherche (hier ein Testbericht) ging noch am selben Tag die Bestellung bei Amazon ein.
Der Ein/Umbau
Zwei Tage später hielt ich die SSD in den Händen. Nun hieß es ran an den Speck.
Mein Plan war folgender:
- Alte Festplatte formatieren und Mac OSX über DVD neu installieren (50GB)
- DVD Laufwerk ausbauen, SSD einbauen und Windows über einen USB-Stick installieren
Wie ich finde ein sehr guter und einfacher Plan, doch leider habe ich meine Rechnung ohne Apple gemacht.
Das Apple-Problem
Ich weiß nicht warum Apple immer mit dem Slogan wirbt, dass ihre Systeme so einfach wären. Denn sie sind es nicht!
So musste ich überrascht feststellen, dass das MacBook nicht von meinem Windows Installations USB-Stick booten konnte, obwohl andere Notebooks kein Problem war.
Nach einer Kurzen Suche fand ich heraus, dass Macs NUR Mac OS von einem Stick installieren können! Windows kann man NUR von CD/DVD installieren – was ist denn das für ein Kindergarten?
Der Ein/Umbau – der zweite Versuch
Nun musste ich meinen oberen Plan natürlich verwerfen, da ich Windows nicht mehr hätte installieren können, wenn das DVD Laufwerk erst einmal draußen war.
Also neuer Plan:
- Alte Festplatte formatieren und Mac OSX über DVD neu installieren (50GB)
- Alte Festplatte ausbauen, SSD einbauen und Windows über DVD neuinstallieren
- SSD ausbauen und Alte Festplatte wieder einbauen
- DVD Laufwerk ausbauen und SSD einbauen
ARGH! – Nun gut, geht nicht anders.
Als ich anfing nach den Anleitugen von iFixit.com die Festplatte auszubauen kam schon das nächste Problem. Die eine Schraube, die die Festplatte befestigt war so enorm festgeschraubt, dass ich den Schraubenkopf und einen Schraubenzieher zerstörte bei dem Versuch diese zu lösen.
Toll – fängt ja gut an. Nun war die Schraube nicht mehr lösbar, also musste schweres Geschütz her und die Schraube musste aufgebohrt werden.
Ich weiß nicht, ob ihr schon mal in euren Notebook rumgebohrt habt aber es war wirklich kein schönes Gefühl. Aber gut nach weiteren 20 Minuten war die Schraube raus.
Nun konnte ich die SSD problemlos einbauen und Windows von der DVD installieren.
Nun kam der lustige Teil, der Ausbau des DVD Laufwerks. Wenn ihr schon mal in das Innere eures MacBooks geschaut habt wisst ihr, dass es keine einfache Angelegenheit ist, da diverse andere Teile das Laufwerk verdecken und somit vorher ausgebaut werden müssen um überhaupt an das Laufwerk ranzukommen.
Übrigens, wenn es bei euch noch nicht der Fall ist, verliert ihr bei diesem Schritt eure Garantie und Gewährleistungsansprüche gegenüber Apple.
Wer hierzu mehr wissen will schaut einfach in die Anleitung von iFixit.
Nach einigem Rumgefrickel war das Laufwerk raus. Phuh
Nun musste die SSD in den Chinesischen Adapter, und genau hier hat man die Qualitätsdefizite zu spüren bekommen die man durch den niedrigen Preis inklusive bekommen hat.
Denn die Stecker passten nicht 100%ig zusammen, da in dem Adapter der mittlere Separator ein wenig zu dick war. Also musste hier das Cutter Messe raus um diesen Missstand manuell zu beheben. Aber nach ein paar Minuten als Chirurg passte die SSD auf den Adapter.
Tief durchatmen und den Adapter nun an die große leere Stelle im MacBook einbauen:
Und so sah dann das Ergebnis aus:
Der Adapter ist minimal dicker als das DVD Laufwerk, weswegen etwas schwieriger war nun die ganzen Teile wieder zusammenzusetzen.
Da die Technik im MacBook extrem klein ist sehen dem entsprechend auch die Anschlüsse aus, und sind EXTREM winzig! Manchmal hatte ich schon Angst diese überhaupt zu berühren. Die Kontakte sind sehr klein und sehr nah bei einander und so gut wie jeder Geräteanschluss ist über einen Adapter an dem Motherboard angeschlossen.
Inbetriebnahme
Tatsächlich ist das MacBook nach der Operation auch wieder angegangen und hat beide Festplatten problemlos erkannt. Bisher funktioniert auch alles wie gewohnt.
Zu Performance will ich noch keine Angaben geben, da ich nun erst einmal dabei bin alles neu zu installieren. Was ich aber bisher sagen kann, ist, dass mir dieses kleine Geräusch fehlt, dass das DVD Laufwerk immer gemacht hat wenn es anging, dieses kleine “Zucken” wenn man so will.
Das ganze Gerät ist des weiteren komplett lautlos, wenn nicht grade ein Flash Video läuft. ![]()
Konfiguration
Bei einer SSD gibt es auch einige Einstellungen, die man am Betriebssystem vornehmen muss sollte, um die Lebenserwartung zu erhöhen. Ein wenig Arbeit nimmt uns Windows 7 (und nur 7) ab und stellt schon mal die Defragmentierung ab und macht ein paar weitere Konfigurationen.
Die weiteren Schritte habe ich aus dieser sehr guten Anleitung wo alle weiteren wichtigen Schritte, wie das deaktivieren des Prefetching und Superfetching beschrieben wird.
Testbericht
Wenn ich ein wenig Zeit mit dem Gerät verbracht habe, werde ich hier auch noch einen gesonderten Erfahrungsbericht schreiben.
Wenn ihr Fragen haben solltet einfach hier als Kommentar posten.
ScreenShot Helper – erleichert den Umgang mit Bildern in der Windows Zwischenablage
Heute mal etwas in eigener Sache: Ich habe mal wieder ein kleines Tool für Windows fertiggestellt welches euch das leben etwas erleichern kann. Die Rede ist von ScreenShot Helper.
Bild 1: Benachrichtigung über eine neue Grafik in der Zwischenablage
ScreenShot Helper ist dafür gedacht Grafiken, die ihr in die Zwischenablage steckt schnell und einfach zu verarbeiten. Ein Bleispiel: Ihr wollt einem Bekannten einen Fehler oder etwas anderes zeigen, dass auf eurem Bildschirm passiert. Wenn ihr nur die Windows Tools verwendet müsst ihr erst einen Screenshot machen, dann Paint (oder ein anderes Bildprogramm) starten die Grafik dort einfügen, das Bild speichern, nun müsst ihr eine Webseite suchen auf die ihr das hochladen wollt um dann schließlich den Link zu bekommen, den ihr eurem Freund geben könnt.
Mit ScreenShot Helper wird dieser Vorgang stark vereinfacht. Das Programm erkennt automatisch, dass eine neue Grafik in der Zwischenablage ist und zeigt euch das Fenster aus Bild1. Nun könnt ihr mit einem Klick das Bild speichern oder es mit ebenfalls einem Klick hochladen und bekommt direkt den Link den ihr weiter verteilen könnt.
Ich bin mir dessen völlig bewusst, dass es sehr viele sehr ähnliche Tools da draußen im Web gibt die diese und noch weitere Funktionalitäten bieten. Ich wollte aber einfach nur ein leichtes schnelles Tool haben, dass genau das macht was ich brauche und dass ich weiter anpassen kann.
Vielleicht könnt ihr ja auch soetwas gut gebrauchen. Hier gehts zum Programm.
Windows Lizenzschlüssel aus der Registry auslesen
Da der Beitrag über das Auslesen des Office Schlüssels sehr beliebt ist, habe ich nun auch das Lesen des Windows Schlüssels als Beispiel verfasst.
Das Vorgehen hierbei ist sogar noch einfacher als beim Office Schlüssel, da es keine Aufteilungen in Versionen gibt! In allen Windows NT Versionen (also alle ab XP) befindet sich der Schlüssel in der Registry unter diesem Pfad:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Bild 1: Der Registryordner mit dem Windows Schlüssel
In diesem Ordner finden wir den Binärwert "DigitalProductId", der viele Hexadezimalzeichen enthält!
Der Code ist hierbei dem aus dem Officebeispiel sehr ähnlich, da er ja auch nichts anderes macht, als den im HEX-Code vorhandenen Key in lesbare Schrift umzuwandeln! Die einzige Schwierigkeit hierbei besteht darin, den Key richtig zusammen zusetzen, denn es wird nicht das komplette Alphabet verwendet um einen Windows Key zu generieren sondern nur diese Zeichen:
B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
Wenn man das beachtet steht einem nichts mehr im Wege! Der Code aus diesem Beispiel stammt ausnahmsweise nicht von mir sondern von vcware.de - danke dafür an dieser Stelle!
Ich habe diesbezüglich wie immer ein kleines Demoprojekt angefertigt, das ihr euch herunterladenkönnt! Download
Bitte berichtet ob es bei euch gut geklappt hat.
Hier könnt ihr euch das komplette kostenlose Programm zum auslesen von Windows & Office key herunterladen. (English & Deutsch)
Windows 7 und seine Schönheitsfehler Teil 2: Die Taskleiste
Letzte Woche habe ich unter Windows 7 etwas sehr seltsames beobachtet. Nach dem ich ein kleines Programm geschrieben hatte, dass ich zwischendurch nutzen wollte, wollte ich dieses an die Taskleiste "pinnen", damit ich es immer schnell griffbereit habe!
Bild 1: Links: Wie es sein sollte. Rechts: So sieht das "Problem" aus
Doch Pustekuchen! Ich konnte das Programm, ja nicht mal eine Verknüpfung, die auf das Programm linkte an die Taskleiste pinnen! Seltsam, denn andere Programme, auch selbstgeschriebene, konnte ich problemlos anpinnen!
Woran kann das liegen? Alle Optionen, die man von anderen Programmen kennt waren nicht da! Die ganze Jumplist hatte nur den Eintrag "Fenster schließen". Die anderen Optionen wie "Programm an die Taskleiste pinnen" waren alle weg!
Die erste Vermutung war natürlich, es liegt am Code! - Son Mist - Also habe ich losgelegt und das Programm Stück für Stück von verschiedenen Codeteilen befreit bis ich garkeinen Code mehr im Programm hatte. Aber das "Problem" war immernoch nicht behoben!
Wie gesagt konnte ich andere Programme, die ich selbst gemacht habe anpinnen, nur dieses eine nicht. Also habe ich das getan, was jeder kompetente Programmierer tun würde, ich befragte Google!
Leider konnte ich nichts wirklich brauchbares finden, das meinen Fall bestätigte. Schließlich wollte ich schon aufgeben und das Projekt neu anlegen, in der Hoffnung es würde nicht wieder auftauchen.
Zu meinem Glück habe ich davor ein Skript (an dem ich zur Zeit etwas herum spiel) verwendet, dass dieses Programm (zusammen mit vielen anderen Dateien) umbenannt hatte. Nun hieß das Programm "ax4b.exe". und Überraschung - ich konnte es anpinnen.
Es lag am Namen!
Als ich dem Programm wieder seinen Originalnamen verlieh konnte ich es wieder nicht anpinnen! Achja, das Programm heißt "Uploadhelper.exe"
Wie es also scheint, sind bestimmte Programme unter Windows 7 von der Fähigkeit befreit sich an die Taskleiste pinnen zu können.
Wie ich dann nach einer weiteren Internetrecherche herausgefunden habe gibt es einen Registryeintrag namens "AddRemovenames" derhier zu finden ist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileAssociation\AddRemoveNames
Bild 2: Der Registryeintrag mit den "verbotenen" Namen
Dieser enthält alle Schlüsselwörter, die alle Programme, die eins dieser Wörter im Namen beinhalten, nicht an die Taskleiste pinnen lässt! Diese Wörter sind:
Documentation;Help;Install;More Info;Readme;Read me;Read First;Setup;Support;What's New;Remove
Und da mein Programm das Wort "help" im Namen hatte wurde es von dieser Regel betroffen.
Es scheint so zu sein, dass Microsoft keine Hilfe oder Setup Programme in der Taskleiste sehen will. Wobei ich wirklich nicht verstehen kann, warum "Documentation" in der Liste steht!
Also hat man als Entwickler nun die Wahl: Entweder man benennt sein Programm um, oder man löscht den entsprechenden Eintrag aus diesem Registryeintrag. Von dem letzteren würde ich allerdings abraten, da es ein enormer Eingriff in die Benutzereinstellungen wäre, und wer weiß, vielleicht benutzen noch andere Dienste diesen Eintrag und funktionieren dann eventuell nicht mehr!
Wenn man von dieser Beschränkung nichts weiß, kann es einen schon in den Wahnsinn treiben, denn wer vermutet denn bitte, dass es an dem Namen liegt?
VB.NET: Dateioperationen mit Fortschrittsanzeige Teil 3 – Wiederaufnahme von Downloads
Wenn man grafische Oberflächen entwickelt wird man irgendwann an dem Punkt kommen wo man Dateien kopieren, verschieben oder herunterladen will. Wenn diese nicht grade wenig und klein sind bietet es sich natürlich an eine Fortschrittanzeige dafür zu erstellen. Damit wird sich diese Serie beschäftigen.
Teil 3 - Wiederaufnahme von Downloads nach einem Abbruch
Wer kennt das nicht, man lädt eine große Datei herunter und plötzlich bricht die Internetverbindung ab. Alles umsonst, und der Download muss neu gestartet werden!
Bild 1: Das Demoprojekt bei der Wiederaufnahme des Downloads
Viele Downloadmanager heutzutage unterstützen das so genannte "wiederaufnehmen" von Downloads, sodass man nach einem Abbruch nicht die ganze Datei von vorne laden muss.
Doch wie funktioniert das? In diesem Teil werden wir das Projekt aus Beispiel 2 um diese Funktionalität erweitern. Und es ist erschreckend einfach und benötigt nur eine geringe Modifikation!
Zunächst einmal die Theorie. Wenn ihr in den Code aus Teil 2 schaut werdet ihr feststellen, dass beim herunterladen der Datei ein Strom aufgebaut wird, aus dem wir die Daten herunterladen und lokal speichern.
Wenn ihr den Code aus dem Form_Closing() Ereignis löscht, und dann einen laufenden Download durch das Beenden des Programms abbrecht, werdet ihr feststellen, dass die "temporäre" Datei nochimmer auf der Festplatte liegt!
Diese Datei ist natürlich nutzlos, da wir nur eine Teilmenge davon geladen haben. Aber da wir herausfinden können, wieviele Bytes wir schon geladen haben wissen wir schon wo wir wieder ansetzen müssen!
Dementsprechend müssen wir den neuen Download nicht an Stelle 0 im Strom starten, sondern an stelle [Anzahl heruntergeladener bytes].
Ich möchte jetzt nicht den ganzen Code hier posten sondern nur die Schlüsselstelle hier:
Dim request As HttpWebRequest = HttpWebRequest.Create(url) request.Proxy = Nothing request.AddRange(CInt(curBytes)) Dim response As HttpWebResponse = request.GetResponse If Not response.StatusCode = HttpStatusCode.PartialContent Then 'falls der Server wiederaufnahme nicht unterstützt bei 0 anfangen curBytes = 0 End IfMan muss beim erstellen des Requests und noch vor dem Response dem Server mitteilen, ab wo er die Daten schicken soll, da wir ja nicht die ganze Datei brauchen!
Dies machen wir mit dem Befehl request.AddRange(CInt(curBytes)) der dafür sorgt, dass der Stream an der von uns gewünschten Stelle startet!
Leider unterstützen nicht alle Server die Wiederaufnahme von Downloads. So kann es vorkommen, dass der Download nicht fortgesetzt werden kann. Diesen besonderen Fall muss man natürlich behandeln.
Wenn wir die Antwort vom Server bekommen (Response) können wir prüfen, welche Statusmeldung der Server zurückgegeben hat. Dafür benutzen wir die Methode response.StatusCode.
Wenn alles gut gelaufen ist und der Server die Wiederaufnahme zulässt bekommen wir den Status Code 206 - PartialContent. Wenn der Server es nicht unterstützt kriegen wir den Code 200 - OK.
Eine komplette Liste mit den Server Responses findet ihr im MSDN!
Wenn wir den Code 200 bekommen müssen wir die Datei wieder von Null laden und müssen darauf mit der Rücksetzung im Code reagieren!
Ich setze in der Demo noch den Proxy auf Null. Das mache ich, da ich ein paar Probleme hatte und der Stream etwas falsch ankam. Ihr könnt es gerne mal ohne diesen Befehl testen und dann hier berichten.
Um das ganze zu testen könnt ihr euch die Demo laden. Startet dann einfach einen Download und unterbrecht diesen irgendwo in der Mitte. Dann startet das Programm neu und startet den selben Download nochmal.
Ihr werdet nun gefragt, ob ihr diese Datei überschreiben wollt (Standartfrage von Windows) und ob ihr dann den Download fortsetzen wollt. Beides mit "Ja" beantworten.
Nun müsste das Programm den Download wiederaufnehmen.
Das Demoprojekt gibt es hier: Download
Teil 1 - Kopieren und Verschieben von Dateien
Teil 2 - Download von Dateien
Teil 3 - Wiederaufnahme von Downloads nach einem Abbruch
Teil 4 - Upload von Dateien













