If your php stores sessions in files, you can just read those files from D. Though that's horribly slow and I don't think php does that by default any more.

But it really depends on how the PHP is configured to see how easy it will be. It might just be a cookie to read then index into a database, or maybe a signed cookie too... no way to tell without looking at the actual thing.

But the php session formats, however they are stored, aren't terribly complex so you should be able to get into it.

On Thursday, 15 January 2015 at 14:38:16 UTC, Steven Schveighoffer wrote:
> On 1/14/15 11:31 AM, Laeeth Isharc wrote:
>
>> To be very clear: in the simple case when you compile your vibe
>> application from multiple source files and diet templates etc, and you
>> will end up with an executable.  This can act as a server directly, or
>> you can make it an internal server on localhost called by php, or you
>> can call it from nginx as a CGI type application depending on the URL.
>
> Pardon me for asking kind of a side question, but is there any online information on how to do this? I am contemplating migrating my in-house php-based application to vibe.d, but I wondered if I have to do it whole-sale (not much gratification until the whole thing is done) or piecemeal (then some parts are php, some are vibe.d, until whole thing is ported). I thought I could do the latter, but I don't know how to interact apache/php with vibe.d. The biggest question I have is how vibe.d and php can share session data. But I also have no idea which server should be in front, and how to call one another ;)


It may be that you have a reason for going with apache, but in case you have not looked into it (or the situation has changed since you last looked), you might consider nginx as a front end given better stability and performance.

If you make D read the PHP authentication then you need to write a new auth  scheme when you have gotten rid of PHP.  So it might be worth at some point considering moving this to an external service called by both D and PHP when  you can do so without breaking anything.

This might be worth a read:
http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/

Thanks everyone for the tips.

-Steve