requinix

You do realize your JSON is completely different from the example, right? JSON doesn't have a "date" type. It's just a string. When you encode the date, do it with the string "/Date(" + the Unix timestamp + ")/".

The N;path syntax for the files handler means to spread the session files N directories deep, so 123456 will be at /hermes/phpsessions/1/2/3/4/123456. Can you look at the session file itself to make sure it has data at all points in the process? It could be encrypted, but even if you can still tell whether there's stuff in there and whether it changes.

Welcome to the world of software development.

When I say to look at examples, I mean look at developer documentation. Not to use an app and guess how it works - find actual technical explanations. But actually implementing OAuth would probably be the best thing for you to do. Like real OAuth. According to the specs. They can expire, sure. Like I said it depends on your application. Random string.

While the client could hold on to the credentials, it shouldn't. Refresh tokens are the better solution. Exactly how access and refresh tokens work depend on your application. Access tokens could be good for a couple minutes or an hour and may or may not be limited to one per user, while refresh tokens are good for a lot longer (possibly indefinitely) and typically have one per device or web session. Since refresh tokens are so powerful they should also be revokable. Access tokens are basically like short-lived sessions, so their time limits should be pretty short - short enough so that they don't live long, but long enough that the client is spending more time issuing requests than refreshing access. The lifetime of refresh tokens are directly tied to how often the user is required to authenticate with your system, so the first question to answer is whether you want to force the user to enter their credentials ever again after the first time. As for the process, 1. Client authenticates and gets an access token with its expiration. 2. Client can then request a refresh token if it wants one. 3. Client uses access token until shortly before it expires, and/or continues until the API returns 401s. 4. To refresh, client uses the refresh token with a specific endpoint to get a new access token (if it hasn't been revoked). 5. Refresh endpoint returns a new access token (and expiration) and client resumes using that. Remember that you can always look around to other APIs, like OAuth, to see how they do it.

If you want to change the HTML markup of the button/image thing then that isn't the code for it. If all you want to do is change the appearance of the "button" then $image looks like what you need - but it's a path to an image, not "back" or "continue". Maybe you have some screenshots that would help explain what you're trying to do?

Did you try changing $image?

The code is suspicious but I'll give the benefit of doubt. http://php.net/manual/pt_BR/language.types.string.php#language.types.string.parsing $script = "<?php \$conecta = mysql_connect('HOST', 'LOGIN', 'SENHA') or print (mysql_error()); mysql_select_db('BANCO', \$conecta) or print(mysql_error()); print 'Conexão e Seleção OK!'; mysql_close(\$conecta); ?>" . $script;

I think the question here is whether "machine client" and "server" have to be separate; both running on the same server would greatly simplify the architecture.

Actually you kinda did: the output from netstat in your first post shows httpd, which is Apache.

It won't help for particularly bad halting errors, but you can use register_shutdown_function to create a failsafe that closes the connection (if not already closed). But... what kind of error is terminating your code yet leaving the process running?

If you look at a number of other projects, particularly open source ones, you'll see most use memorable port numbers (eg, 1337, 6666/7, 8080, 9000) above 1024 (ports 1-1024 are restricted in Linux).

Yeah, the forum doesn't have any kind of delete or deactivate button you can hit. I don't see any personal information in your account or your post (except the broken URL, which I've removed) so I would suggest simply forgetting about it.

This is not acceptable behavior. Thread pruned.

As said, PHP does not distinguish between 123 and 123.0. If you must have 123.0 then you need to do that manually. Which would suck. Are you absolutely sure it has to be a float? Have you tried an integer and the service is returning an error?

You're comparing with $first_name but you never update that value.

Right now I don't care about $json. Listen to me, okay? This code: <?php ini_set('display_errors',"1"); header('Content-Type: text/plain'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://eu.myconnectwise.net/v2017_1/apis/3.0/services/tickets/13934"); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: basic ' . base64_encode('#######'.'+'.'##########'.':'.'##########'))); curl_exec($ch); curl_close ($ch); ?>Put the right username and password in there, then run it. What is the output? If there's sensitive information then redact it, but otherwise post exactly what you see.

I know who and what you've speaking of and I haven't seen it happening. If it does happen to you then PM me directly about it. If you think it's happening to other people then use the reporting function and the staff will investigate, though we likely will not tell you what/if anything happens.

Do the work during an AJAX request, not on a regular page load, and then you can do anything you want: message, spinning thing, busy cursor, whatever.

Of course not: the API call is happening on your server, not in the browser. So how about we return to what I was asking about before. That test script I posted - what do you get if you run that?

Okay... Can you solve that problem on your own?

Try running just this: <?php ini_set('display_errors',"1"); header('Content-Type: text/plain'); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "https://eu.myconnectwise.net/v2017_1/apis/3.0/services/tickets/13934"); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: basic ' . base64_encode('#######'.'+'.'##########'.':'.'##########'))); curl_exec($ch); curl_close ($ch); ?>

What is the contents of $json?

$.cookie can both get and set the cookie.

Access keys only work if you can assign them to each endpoint. You could do that for a mobile app, but that's not the best way to go about it. Access tokens would be more appropriate. Rather than send the login information for every request, requiring that you hold onto that information the whole time the user is on the app, you only log them in once. The server then returns a temporary token that can be used for subsequent requests in lieu of the credentials; it's time-restricted so the token doesn't last forever, and to keep the app working without requiring a login every 5 minutes you add to the API something which can generate a new token if requested (which the app would do when the token is close to expiring).