I have written the logic to get the user-name of registered users from DB and used it as URL prefix in my web.php and grouped some routes using those name.
On my local machine it seems to working fine. In case of server users can register, but that user is not able to access the further routes with their username as prefix. When tried to access it shows 404.
When did the research it was due to routes not getting cleared. So, after new user registration successfully added the below code to clear cache and route. but still not working. How can i achieve this.
Added on top;
use Illuminate\Support\Facades\Artisan;
Artisan::call('route:clear');
Artisan::call('cache:clear');
I have tried clearing cache manually it works fine. But i am trying to do it via code automatically. Also FYI i am not getting any error. because i have tried adding logs and used
Artisan::output()
to check it, shows success message without any error
I am not sure if you can call the default laravel artisan commands via that facade. What I am sure is that if you want to programmatically delete the cache you should use the Cache facade like so
use Illuminate\Support\Facades\Cache;
Cache::flush();
More info about it in the documentation.
Related
https://github.com/osiset/laravel-shopify/wiki/Installation
I follow the step to add Uninstallation Job, But not getting any webhook call after uninstalling the app.
So when I try to install getting an error.
There’s no page at this address.
Can anyone help me with an example to check or debug that uninstallation Process?
It is an exercise in two parts. One, your App needs to listen to an endpoint. Create an endpoint that accepts webhooks and has the capability of ensuring security with the Shopify HMAC. Test your endpoint is working with Postman or some other simple too. By working we mean NOT 404. Now setup your webhook with the App API key you have, in your test store. Usually this is done by installing your App. Now uninstall. Watch your endpoint logs. Nothing much else to it.
If you are getting 404 errors, your App is not working properly. Work on that aspect of your web development before trying more complex things.
Did you type in ‘php artisan vendor:publish --tag=shopify-jobs‘
And also check if there is an Job at ‘App/Jobs/AppUninstalledJob‘
Also make sure that your shopify-config looks like this:
'webhooks' => [
[
'topic' => env('SHOPIFY_WEBHOOK_1_TOPIC', 'app/uninstalled'),
'address' => env('SHOPIFY_WEBHOOK_1_ADDRESS', env('APP_URL').'webhook/app-uninstalled')
]
]
Now you should also be aware of the fact that the webhook will not work on your local installation. If you went through all of the steps correctly and deploy your app to a public Server it will work.
I am backing a web app with a Flask API that returns custom error codes. The API runs through Apache and the WSGI module, in daemon mode.
I included a WSGIErrorOverride Off instruction in the Apache conf file for the API (which is supposed to be the default but I included it anyway).
Yet anytime my Flask app returns a custom error code (they work when I run the app using the built-in server), Apache sends an error 500. How can I prevent that?
Thanks to comments by duskwuff and Graham Dumpleton, I found that the problem doesn't come from Apache WSGI but from my Flask app.
More precisely, I was using the Flask-RESTful package, which is in charge, among other things, of transforming my views' return values into actual responses.
When those views are decorated (here with an equivalent of #login_required), those decorators are called by the Flask-RESTful package itself, and when an exception is thrown, something goes wrong.
For some reason, my app returns the custom error when I run the built-in server and an error 500 when I run it over Apache. Not quite sure why yet, I'm guessing Flask-RESTful is doing something that is not WSGI-compliant. I was on the verge of dropping it anyway for other reasons, so I'm OK with this solution.
Update: it looks like the problem does indeed come from Flask-RESTful: https://github.com/flask-restful/flask-restful/issues/372
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.
I'd like to know how to troubleshoot IIS URL Rewrite module and custom rewrite providers?
I am trying to do a POC on the URL Rewrite Module for our app. Our mappings are all in the database so I thought using the provider that comes as a sample. Got everything installed and configured, as instructed. Created the stored procedure as well. Now when I hit the alias URL I receive HTTP Error 500.50 - URL Rewrite Module Error. Here are the details about the error:
Module RewriteModule
Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x80070585
In SQL Profiler I see no calls to my stored procedure. The app pool is running under my account (admin rights). No errors in the event logs.
Are there any logs I could look into for more information on what's happening?
I got it working after two days of digging. The samples are good but not good enough: simply using supplied DLLs with supplied config entries doesn't work (for many reasons).
What I ended up doing was getting rid of the DLLs from samples and creating my own provider using the source code from samples and information from this article: Developing a Custom Rewrite Provider for URL Rewrite Module. Then IIS started loading my provider. But in order to make it work correctly I had to get deep understanding of module's config system.
So my answer to my own question -- don't relay on samples alone, they don't work out of the box. Instead, RTFM :) The best place to start is here: URL Rewrite Module Configuration Reference
My Kohana app runs perfectly on my local machine.
When I deployed my app to a server (and adjust the config files appropriately), I can no longer log into the app.
I've traced through the app login routine on both my local version and the server version and they both agree with each other all the way through until you get to the auth.php controller logged_in() routine where suddenly, at line 140 - the is_object($this->user) test - the $user object no longer exists!?!?!?
The login() function call that calls the logged_in() function successfully passes the following test, which causes a redirect to the logged_in() function.
if(Auth::instance()->login($user, $post['password']))
Yes, the password and hash, etc all work perfectly.
Here is the offending code:
public function logged_in()
{
if ( ! is_object($this->user))
{
// No user is currently logged in
url::redirect('auth/login');
}
etc...
}
As the code is the same between my local installation and the server, I reckon it must be some server setting that is messing with me.
FYI: All the rest of the code works because I have a temporary backdoor available that allows me to use the application (view pages of tables, etc) without being logged in.
Any ideas?
I solved the problem (DUH!).
The answer was that the cookie.php config file had $config['domain'] = 'localhost'. Setting this to the actual domain that the app is installed in magically made my life happy again!
Thanks everyone for your help and interest.