Obteniendo un dispositivo UDID de .mobileconfig

Estoy intentando escribir una función similar a http://whatismyudid.com/ que, luego aprobada, devolverá el UDID de los usuarios y lo almacenará en una base de datos para futuras referencias con ese usuario.

He escrito un archivo .mobileconfig xml doc que se abre en el Instalador de perfiles muy bien, pero cuando digo que instale el perfil responde con [alert] Invalid Profile pero sin cuerpo de alerta. Sin descripción, sin código, sin ayuda.

Soy nuevo en el juego de configuración móvil así que cualquier ayuda me emocionaría.

Aquí está mi archivo de configuración:

     PayloadContent  URL http://apps.mortlabs.com/device/retrieve.php DeviceAttributes  UDID IMEI ICCID VERSION PRODUCT   PayloadOrganization MortLabs.com PayloadDisplayName Profile Service PayloadVersion 1 PayloadUUID B958E359-34C2-42F4-BD0C-C985E6D5376B PayloadIdentifier com.mortlabs.profile-service PayloadDescription This temporary profile will be used to find and display your current device's UDID. PayloadType Profile Service   

El perfil se inicializa navegando a http://apps.mortlabs.com/device/enroll.php con safari móvil

    Descubrí que al usar lo anterior, el Ipad / Iphone hablaba de Apache: la publicación de Kyle2011 en https://discussions.apple.com/thread/3089948?start=0&tstart=0 completaba el rest de la solución. .

    Básicamente, en la parte inferior de la página retrieve.php, debe redirigir el navegador a un directorio utilizando una línea similar a la siguiente:

     header("Location: https://www.example.com/enrolment?params={$params}"); 

    Donde la inscripción es un directorio, esto llama al DirectoryIndex (típicamente index.php) que luego puede mostrar cosas a su usuario.

    Para poblar la variable $ params, necesita la siguiente línea en la parte superior de su script retrieve.php

     $data = file_get_contents('php://input'); 

    A continuación, puede analizar la cadena $ data para obtener lo que necesita (intente con file_put_contents("data.txt", $data); o el ejemplo de Kyle2011)

    También cambié el UDID de la carga útil a algo diferente usando udidgen en una terminal en una Mac en lugar de usar whatismyudid.com.

    Actualización: desde iOS 7.1, algunos de los archivos (el .plist IIRC) deben servirse sobre https: // – no se instalarán si todo se sirve en http: // – probablemente sea mejor que se sirva todo, incluido el archivo .ipa sobre https: // para asegurar que los cambios futuros en el lado de Apple no causen problemas.

    Nota sobre la última página (CARPETA).

    Si desea utilizar un script de página para la redirección final en lugar de una carpeta.

    puedes cambiar esto:

    encabezado (“Ubicación: https://www.example.com/enrolment?params= {$ params}”);

    por

    encabezado (“Ubicación: https://www.example.com/enrolment.php?params= {$ params}”, verdadero, 301);

    Fuente: función de encabezado en php.net manual

    es trabajo !

    Intenta configurar la URL a una dirección sin la extensión .php. Esto resolvió mi problema. Ahora mi único problema es que no puedo averiguar cómo recuperar los datos enviados desde el dispositivo iOS a mi servidor. No parece estar en la variable $ _POST.

    El error que está obteniendo es porque iOS espera que su URL de servicio de perfil (a la que envía su UDID) devuelva un perfil de configuración (es decir, un archivo .mobileconfig ). Actualmente capturo los UDID de dispositivos sin devolver este perfil; mis dispositivos generan la alerta que describes pero los datos están en mi servidor.

    Como referencia, aquí está el archivo (muy) simple de PHP que utilizo para capturar los datos:

     < ?php // set file to write $file = 'device_data/data.p7s'; $fp = fopen($file, 'w') or die('Could not open file!'); fwrite($fp, $HTTP_RAW_POST_DATA) or die('Could not write to file'); fclose($fp); ?> 

    La clave aquí es el uso de la variable $HTTP_RAW_POST_DATA para capturar el cuerpo de solicitud HTTP exactamente como se envió, sin intentar analizarlo en los pares de nombre / valor usuales. Sugiero leer la documentación en este punto, pero realmente no dice mucho.

    Consejo de seguridad: lo que el usuario envíe en el cuerpo de la solicitud, usted está escribiendo en un archivo en su servidor. Si el usuario decide enviar un script de shell, un archivo PHP u otro contenido ejecutable, luego visita la URL del archivo que crea, puede ejecutar el código que acaba de cargar en su servidor web. Por lo tanto, asegúrese de que no se pueda acceder al archivo al que escribe a través de HTTP . (Un archivo .htaccess podría ser el truco o escribir en algún lugar fuera de la raíz web).